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ABSTRACT 


The  Navy  Automated  Transportation  Documentation  System 
(NAVADS)  is  a  multiple  subsystem,  multi-modal  automated  data 
processing  and  management  information  system.  The  system  is 
designed  to  accept,  release,  consolidate,  and  track  material 
requests  at  Naval  stock  points. 

This  thesis  will  address  some  of  the  basic,  current,  and 
historic  issues  that  confront  the  system  and  those  issues 
which  have  found  solutions  within  the  NAVADS  framework.  The 
paper  will  also  provide  a  rudimentary  description  of  the 
system  operation  in  terms  of  the  files,  programs,  and  solu¬ 
tion  methods  used  by  the  system  to  perform  its  mission. 
Additionally,  the  thesis  will  provide  a  brief  review  of  a 
civilian  freight  operation  within  the  ADP  environment.  The 
thesis  is  designed  to  work  as  a  primer  to  provide  an  orienta¬ 
tion  in  basic  NAVADS  operations  and  the  prob^matic  and  opera 
tional  environment  in  which  it  operates. 
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INTHODCCTION 


I  . 

The  Navy  Automated  Transportation  Documentation  System 
(NAVADS)  is  a  Naval  Supply  Systems  Command  (NAVSUPSYSCOM) 
sponsored  automated  data  processing  (ADP)  system  project  de¬ 
signed  to  coordinate  the  management,  planning,  and  control  of 
material  movement  at  naval  stock  points. 

NAVADS  represents  an  important  benchm.ark  in  the  standard¬ 
ization  of  Navy  stock  point  operations.  It  provides  stock 
point  managers  with  the  capability  to  automate  material  trans¬ 
portation  consolidation  and  documentation  processes.  Addition 
ally,  NAVADS  can  maintain  and  provide  material  location  data 
for  shipments  passing  through  or  originating  at  a  stock  point. 
NAVADS  will  allow  Navy  stock  points  of  the  future  to  partici¬ 
pate  in  Defense  Department-Wide  physical  distribution  service 
networks  through  its  Defense  Data  Network  (DDN)  interface 
capabilities  and  conformance  in  handling  standardized  defense 
logistics  data  structures. 

NAVADS  consists  of  three  major  subsystems.  Within  these 
three  subsystems  there  resides  five  operating  modules:  The 
Basic  Data  Package  (BDP)  (Subsystem  I,  Module  I),  The  Manage¬ 
ment  Control  System  (MCS)  (Subsystem  II,  Module  II),  and  the 
Automated  Documentation  System  (Subsystem  II,  Modules  III, 

IV  and  V) .  NAVADS  operates  as  part  of  an  integrated  triad 
consisting  of  the  Uniform  Automated  Data  Processing  System- 


stock  Point  (UADPS-SP).  and  the  Navy  Integrated  Storage  Track¬ 
ing  and  Retrieval  System  (NISTARS) . 

This  thesis  provides  a  general  introduction  to  NAVADS 
and  identifies  some  key  historical  and  current  issues.  There 
are  many  issues  facing  the  project  managers  of  NAVADS.  These 
issues  range  from  project  accountability  to  issues  dealing 
with  maintaining  NAVADS  as  a  viable  and  adaptive  system  as 
data  processing  and  logistics  technology,  methods,  and  proce¬ 
dures  change.  Additionally,  managers  must  concern  themselves 
with  issues  that  may  change  the  functional  environment  within 
which  the  system  operates.  These  issues  may  mandate  a  greater 
ability  to  anticipate  future  requirements  in  maintenance  and 
life  cycle  management  of  NAVADS  hardware  and  software  facili¬ 
ties.  Some  of  these  current  issues  include: 

1.  Economic  analysis  efforts  to  measure  the  effect  of 
NAVADS  on  operating  efficiency. 

2.  Implications  of  the  ADA  programming  language  for  NAVADS. 

3.  Increased  retrograde  accountability  for  aviation  re- 
pairables  to  be  held  within  the  Navy  Stock  Fund  (NSF)  . 

4.  Aspects  for  security  and/or  processing  continuity  for 
NAVADS . 

5.  How  the  NAVADS  local  delivery  system  can  better  serve 
local  delivery  documentation. 

6.  Problems  faced  by  the  communications  and  area  network 
software  systems  within  the  NAVADS  operating  environment. 

Additionally,  this  thesis  will  view  NAVADS’  capabilities 
to  handle  some  historic  issues  in  Navy  physical  distribution 
such  as: 
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1.  Material  consolidation  and  transportation  selection; 

2.  Shipping  Document  preparation; 

3.  Material  Transshipment; 

4.  Stock  Point  Material  Tracking. 

The  research  for  this  thesis  was  conducted  over  a  five 
month  period.  The  major  portion  of  this  time  was  spent 
collecting  and  reviewing  current  literature  and  service  m.an- 
uals  for  the  NAVADS  system.  Field  trips  were  conducted  to 
NSC  Oakland,  CA,  Naval  Supply  Systems  Command  (0611) ,  Washing¬ 
ton,  DC,  and  Fleet  Material  Support  Office  (FMSO)  Codes  (92) 
and  (93) ,  Mechanicsburg ,  PA. 

The  following  chapter  will  provide  an  historical  per¬ 
spective  of  the  changes  in  logistics  procedures  and  methods 
within  the  defense  community.  This  will  help  in  understanding 
the  development  and  need  for  NAVADS  within  the  broad  context 
of  the  overall  evolution  of  military  and  naval  logistics. 
Chapters  3  and  4  will  discuss  the  system's  basic  operation 
and  technical  methods  to  handle  some  of  the  historic  issues 
that  have  confronted  stock  points  over  the  years .  Chapter  5 
will  provide  a  brief  survey  of  some  of  the  current  issues  in¬ 
volved  with  NAVADS.  Chapter  6  will  have  a  brief  overview  on 
ADP  methods  used  by  a  civilian  express  freight  firm  to  operate 
their  transportation  operations.  Chapter  7  will  provide  a 
summation  and  recommendations  toward  possible  solutions  to 
some  of  the  current  issues. 


HISTORICAL  PERSPECTIVE 


II  . 

NAVADS '  development  must  be  taken  in  the  context  of  the 
historically  progressive  requirements  placed  upon  the  military 
logistics  establishment.  In  1962  the  Military  Standard  Trans¬ 
portation  and  Movement  Procedures  (MILSTAMP).  program  was  es¬ 
tablished  as  a  Department  of  Defense  (DOD)  standard  requiring 
fundamental  changes  in  transportation  practices .  These 
changes  were  needed  in  the  face  of  growing  demands  for  an 
ever  widening  variety  and  quantity  of  material  commensurate 
with  increases  in  timeliness  and  accuracy  of  its  delivery. 
These  requirements  were  necessitated  by  the  changing  criti¬ 
cality  and  fluidity  of  the  strategic  and  tactical  environment 
as  well  as  dilation  of  Navy  responsibilities  worldwide.  The 
primary  mission  of  quick  and  accurate  delivery  while  dealing 
with  the  problem  of  the  distribution  of  limited  resources 
within  DOD  required  the  development  of  projects  that  would 
minimize  hiiman  error  wherever  possible,  consolidate  resources, 
and  provide  for  efficient  and  effective  use  of  stock  and 
transportation  assets.  To  accomplish  these  aims  the  implemen¬ 
tation  of  MILSTAMP  required; 

1.  Advanced  Shipment  Planning 

2.  Automatic  Preplanning  of  Shipment  Units 

3.  Mechanized  Preparation  of  Shipping  Documents 


In  1962,  wlien  ADP  systems  were  still  in  their  infancy, 
hardware  consisted  of  batch  operating  systems  of  undiversified 
capability  limited  to  sorting,  comparisons,  and  some  mathe¬ 
matical  and  scientific  applications.  Software  was  just  coming 
into  the  COBOL  developmental  stage  and  real  time  applications 
were  non-existent.  Document  preparation  and  consolidation 
was  done  via  eighty  card  column  parameter  cards  prepared  by 
clerks  with  keypunch  machines  and/or  paper  tape  which  were 
read  onto  magnetic  tape  and  queued  into  a  particular  system 
for  sequential  processing.  VJhile  some  labor  and  logic  inten¬ 
sive  clerical  activities  were  relieved  by  the  sort  and  compare 
abilities  that  computers  offered,  the  operating  environment, 
within  which  these  facilities  were  in  use,  demanded  more  as 
the  responsibilities  for  the  operating  forces  of  the  DOD 
were  increased.  These  increases  required  more  resources  at 
a  faster  rate  which  progressively  outpaced  the  capabilities 
of  the  older  analog-batch  systems.  Time  was  now  considered 
a  new  limited  resource.  Ordering,  preparing,  packing,  and 
shipment  of  material  goods  now  not  only  needed  quantity  and 
quality  but  speed  and  an  audit  trail  to  maintain  accounta¬ 
bility  concordant  with  the  increase  in  material  transactions. 

In  1977  DOD  and  the  individual  armed  services  logistics 
organizations  began  to  develop  their  own  consolidation  and 
documentation  systems,  such  as.  Army  SPEEDEX,  the  Air  Force 
Shipment  Documentation  Control  System  and  the  Defense  Logis¬ 
tics  Agency's  MOWASP  and  MOFAST  systems.  All  of  these  systems 


were  developed  for  a  twofold  reason.  The  first  was  to  take 


advantage  of  the  advances  in  AD?  technology  now  capable  of 
virtual  and  user  transparent  operations  in  a  real-time, 
on-line  environemtn  operated  by  personnel  who  are  not  required 
to  be  computer  specialists  or  experts.  The  second  reason  was 
to  move  toward  consolidation  and  standardization  of  transpor¬ 
tation  and  logistics  operations  within  the  DOD  logistics 
organization  and,  of  course,  the  armed  services  themselves. 

This  evolution  was  started  by  the  introduction  of  MILSTAMP 
and  its  related  program  for  the  standardization  and  distribu¬ 
tion  of  automated  logistics  document  standards.  Military 
Standard  Requisition  and  Issue  Procedures  (MILSTRIP) .  Follow¬ 
ing  on  its  heels  were  the  benchmarking  and  establishment  of 
Issue  Priority  Groups  (IPS)  and  a  standardized  processing 
and  delivery  priority  system  called  the  Uniform  Material  Move¬ 
ment  and  Issue  Priority  System  (UMMIPS) . 

Several  years  later  the  groundwork  for  the  development  of 
the  Navy's  own  transportation  consolidation  and  documentation 
system  was  begun  with  the  publication  of  the  Fleet  Material 
Support  Office  (FMSO)  NAVADS  Requirements  Statement  in 
February  1978.  This  FMSO  Requirements  Statement  cited  the 
problem  facing  Navy  stock  points  at  this  juncture  [Ref.  1: 
p .  3  ]  ; 

"Presently  the  Navy  transportation  system  reacts  to  the 
supply  issue  action  described  in  MILSTRIP  by  manual 
preparation,  processing,  and  control  of  transportation 
documents  in  unwieldy,  slow  and  inefficient  methods. 

Some  Navy  shipping  activities  are  performing  these 


functions  on  a  limited  basis  by  combining  a  manual  and 
mechanized  augmentation  system  to  fit  their  local 
operation . " 

Briefly,  each  Navy  shipping  activity  was  operating  in  an 
"ad  hoc"  environment,  combining  manual  and  clerical  intensive 
ancillary  activities  with  limited  ADP  resources  resulting  in 
a  vast  and  individually  unique  collection  of  incompatible 
systems.  Each  system  had  its  own  set  of  data  elements,  pro¬ 
tocols,  and  output  products  which  had  evolved  to  conform  to 
local  requirements.  This  lack  of  standardization  led  to  an 
inability  to  properly  develop  transportation  management  goals 
such  as  preplanning,  consolidation  of  shipping  units,  and 
reduction  in  expenditures  of  Service-Wide  Transportation 
funds  (SWT).  The  basic  goal  of  NAVADS ,  as  with  any  other 
system  introduced  in  a  military  or  civilian  working  environ¬ 
ment,  is  to  free  personnel  from  detailed  logic  and  labor 
intensive  work.  This  allows  the  retargeting  of  human  re¬ 
sources  to  higher  considerations,  such  as  strategic  planning 
within  one's  own  organization  in  the  areas  of  preplanning, 
control,  and  management  of  the  logistics  transportation 
environment , 

The  goals  of  NAVADS  are  as  stated  in  the  NAVADS  Functions 
Description  [Ref.  2:p.  5]; 

1.  Automate  Shipment  Planning 

2.  Mechanize  Shipment  Documentation  Preparation 

3.  Track  Material  Movements  at  Supply  Centers 

4.  Conserve  Operational  and  SWT  Funds 


5.  Meet  UM!1IPS  Time  Frames 


6.  Measure  Supply  Center's  Complete  Performance 

NAVADS  must  be  logically  viewed  and  understood  as  being 
an  integral  part  of  a  greater  stock  point  automated  network 
consisting  of  the  Burrough's  Medium  System,  the  NISTARS-TANDEM 
system  and  the  TANDEM-SPLICE  system,  as  it  will  exist  in  its 
final  configuration.  Presently  NAVADS  is  operating  within  a 
network  consisting  of  a  Perkin-Elmer  minicomputer  system 
utilizing  TAPS  I  as  an  interim  measure  until  the  installation 
of  the  TANDEM-SPLICE  hardware  and  implementation  of  the  TAPS 
II  system. 

The  description  of  the  three  NAVADS  subsystems  and  modules 
will  be  discussed  in  the  following  two  chapters.  It  is  im¬ 
portant  to  recognize  that  NAVADS  is  an  interfaced  system, 
within  a  larger  system,  existing  to  provide  the  specific 
function  of  furnishing  logical  collation  of  basic  data  pack¬ 
age  elements  and  entities  to  output  reports,  issue  material 
orders,  automate  documentation,  and  perform  shipment 
consolidation . 

Recognizing  the  diversity  of  Navy  stock  points,  NAVADS 
is  structured  to  satisfy  these  varietal  mixes  of  area  respon¬ 
sibilities,  constraints  and  perogatives.  The  FMSO  Functional 
Description  [Ref.  2;p.  3]  states: 

"Sufficient  options  will  be  provided  in  the  modules  to 
accomodate  individual  stock  point  preferences.  In 
addition  to  the  tailored  application  programs  that  will 
be  developed  for  the  various  functional  areas  of  NAVADS, 
a  report  generator  capability  will  also  be  available  to 


III.  BASIC  NAVADS  STRUCTURE  FOR  SUBSYSTEMS  I  AND  II 

NAVADS  consists  of  three  major  subsystems  containing  five 
operational  modules  generating  the  required  reports ,  documents , 
and  updates  needed  to  meet  modern  Navy  Stock  Point  material 
operations.  These  Subsystems  are:  Subsystem  I,  The  Basic 
Data  Package  (BDP) ;  Subsystem  II,  The  Management  Control 
System  (MCS) :  Subsystem  III,  The  Automated  Documentation 
System.  Subsystem  III,  the  heart  of  the  NAVADS  Automated 
Documentation  system  on  the  minicomputer,  will  be  discussed 
in  the  following  chapter. 

This  chapter  will  give  a  brief  overview  of  the  first  two 
subsystems,  their  related  modules  and  the  basic  files  and  pro¬ 
grams  which  link  them  together  and  provide  update  and  data 
communications  capability  with  the  NAVADS  system  internally 
and  with  the  outside  environment. 

A.  SUBSYSTEM  I 

Subsystem  I,  The  Basic  Data  Package  (BDP),  is  composed  of 
.Module  I,  it  is  resident  within  the  Burroughs  Medium  System 
hardware.  The  data  required  to  support  mechanized  physical 
distribution  and  documentation  efforts  are  great  in  magnitude. 
Within  the  environment  of  the  BDP  are  the  sum  total  character¬ 
istics  of  the  two  basic  data  entities  used  in  NAVADS,  the 
National  Item  Identification  Number  (NIIN)  and  the  Unit 
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Identification  Code  (UIC).  .  The  BDP  consists  of  those  data 
elements  which  describe  the  peculiarities  of  both  the  requisi 
tioned  material  and  the  ultimate  destination  of  the  material 
and  other  factors  which  affect  shipping  processes  in  terms 
of  time,  documentation,  shipping  method,  and  consolidation. 

The  data  elements  of  these  entities  are  updated  by  a  num¬ 
ber  of  external  activities  such  as  the  Defense  Logistics 
Service  Center  (DLSC) ,  the  Defense  Automatic  Addressing 
Systems  Office  (DAASO) ,  and  Navy  Inventory  Control  Points 
(ICP).  Updates,  reformats,  and  new  entries  are  handled  by 
the  Basic  Data  Package  Maintenance  System  (BDPMS) .  This 
system  accepts  information  from  a  variety  of  input  sources, 
such  as  CRT  data  entries,  parametric  card  images  (by  either 
CRT  screen  images  or  actual  80  column  cards)  and  by  AUTODIN 
(tape  or  card) .  Data  maintenance  is  performed  on  four  basic 
files  which  make  up  the  BDP: 

1.  NFF  -  NAVADS  Freight-Hazardous  Data  File 

2.  NNF  -  NAVADS  Name  and  Address  File 

3.  CRIF  -  NAVADS  Cargo  Routing  Information  File 

4.  NEF  -  NAVADS  Exception  File 

The  NFF  contains  characteristics  on  each  item  in  stock  at 
a  NAVADS  site,  keyed  on  the  NIIN  data  entity.  The  file  main¬ 
tains  information  on  those  data  elements  which  will  affect 
the  issuance,  handling,  packing  requirements,  and  documenta¬ 
tion  of  the  item  in  order  to  effect  successful  shipment,  by 
whatever  means  appropriate,  to  keep  within  UMMIPS  time  frames 


and  cargo  handling  regulations.  The  data  format  of  the  NFF 
is  shown  in  Table  1  as  extracted  from  the  NAVADS  Data  Specifi¬ 
cations  [Ref.  3:pp.  3-65-3-66]  and  the  NAVADS  Subsystem  User's 
Manual  [Ref.  4:pp.  2-3-2-5].  The  file  is  maintained  on  a  disc 
pack  and  has  a  576  byte  maximum  record  size  for  each  NIIN 
carried  by  the  stock  point.  the  NFF  conforms  to  the  Navy 
Blocked  Random  file  format  as  do  all  the  files  in  Subsystem  I, 
in  order  to  accomodate  specifications  calling  for  both  random 
and  sequential  accessing  capabilities. 

The  NNF  contains  the  address  data  for  customer  activities 
receiving  material  from  a  NAVADS  stock  point.  Information  ob¬ 
tained  here  is  keyed  on  Unit  Identification  Codes  (UIC)  (in¬ 
cluding  the  Service  Designator  Code  (SDC) ) .  The  NNF  is  used 
to  store  plain  language  parcel  post  and  freight  addresses  as 
well  as  aerial  and  water  port  points  of  embarkation  (POE)  and 
debarkation  (POD) .  The  data  format  for  the  NNF  are  shown  in 
Table  2  as  extracted  from  the  NAVADS  Data  Base  Specifications 
[Ref.  3;pp.  3-74-3-75]  and  the  NAVADS  Users  Manual  [Ref.  4:pp. 
2-5-2-6].  The  file  is  maintained  on  a  disc  pack  and  has  a 
1200  byte  maximum  record  file  size  for  each  UIC.  It  conforms 
to  the  Navy  Blocked  Random  file  format  to  accomodate  random  or 
sequential  access. 

The  NNF  receives  inputs  and  returns  outputs  using  some  of 
the  same  programs  as  the  NFF,  specifically,  J-XJlB  and  J-XJlD. 
The  NNF  also  provides  information  for  output  for  programs 
J-XJ2B  and  J-XJ2C  to  provide  shipping  data  for  the  real  time 
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and  batch  issuing  systems.  A  summary  of  specific  Subsystem 
I  and  II  programs  are  in  Appendix  A- 

The  CRIF  is  a  file  entity  established  by  each  NAVADS  site 
to  provide  routing  instructions  for  logical  and  efficient 
shipment  of  material  to  various  customer  locations  or  activi¬ 
ties.  The  file  maintains  four  air  and  four  surface  routing 
channels  for  each  UIC.  "Outchop"  cutoff  dates  are  kept  for 
each  mobile  UIC  and  routing  channel-  The  CRIF  shipping  data 
file  is  a  revolutionary  concept  in  transportation  efficiency. 
It  ensures  the  material  shipping  method,  routes  and  channels 
are  temporally  compatible  with  vessel  movements  or  afloat 
staff  location  changes  in  geographic  or  organizational  respon¬ 
sible  areas  worldwide.  Until  NAVADS,  this  process  had  been 
done  on  a  manual  basis  depending  solely  on  human  initiative 
and  logic  skills.  The  data  format  for  the  CRIF  is  shown  in 
Table  3  as  extracted  from  the  NAVADS  Data  Base  Specifications 
[Ref.  3;pp.  3-57-3-58]  and  the  NAVADS  Users  Manual  [Ref.  4: 
pp.  2-6-2-3] .  As  can  be  seen  from  the  table,  the  air  and 
surface  shipping  channel  information  sections  contain  special¬ 
ized  data  commensurate  with  appropriate  modes  of  shipment 
either  air  or  surface.  The  CRIF  is  maintained  on  a  disc  pack 
and  has  an  800  byte  maximum  record  size  for  each  UIC  so  chosen 
to  be  data-stored  by  a  particular  NAVADS  site.  The  file  con¬ 
forms  to  the  Navy  Blocked  Random  file  format  providing  for 
random  or  sequential  access. 


The  last  file  making  up  the  BDp  is  the  NEF  which  is  used 


for  storing  report  information  on  exception  aspects  of  the 
BDP  for  later  use  in  formulating  different  reports.  The  MEF 
is  essentially  a  holding  or  a  scratch  file  for  use  in  the 
update  interface  for  various  sub-files  at  the  local  EAVADS 
sites  and  the  master  file  maintenance  site  at  Norfolk.  The 
file  is  held  on  a  disc  pack  and  each  sub-file  is  800  bytes 
long.  The  NEF  file  and  its  sub-files  are  listed  in  Table  4. 
The  file  and  its  sub-files  conform  to  the  Navy  Blocked  Random 
file  format.  The  NEF  interacts  with  the  NFF ,  the  NNF,  and 
NAVMTO  via  the  programs  listed  in  Appendix  A. 

For  purposes  of  working  with  the  BDP,  the  NEF  interacts 
mainly  with  the  J-XJIB,  J-XJIC,  and  J-XJIG  programs.  The 
Real  Time  NFF/NNF  Update  Program  writes  NFF  update  data  ex¬ 
ceptions  to  the  NEF.  Later  this  information  is  punched  on 
AUTODIN  card  and  sent  to  NSC  Norfolk  for  inclusion  into  the 
Master  NFF  update.  The  NNF  Update  Program  allows  only  the 
file  maintenance  site  to  write  updates  to  the  MEF.  These  are 
later  blended  into  the  individual  NAVADS  sites'  NNF ' s .  This 
enhances  the  concept  of  viewing  the  NEF  only  as  a  scratch  or 
holding  file  for  temporary  use  in  the  updating  process.  The 
NEF  is  most  actively  used  in  the  operation  of  Subsystem  II 


which  is  a  multi-functional  module. 


B.  SUBSYSTEM  II 


Subsystem  II  is  the  NAVADS  Management  Control  Subsystem 
which  is  comprised  of  Module  II.  The  Management  Control 
Subsystem  (MCS),  is  the  central  operating  module  of  NAVADS. 

The  MCS  has  a  multitude  of  operational  responsibilities  in 
terms  of  collating,  filing,  and  queuing  a  multiplicity  of 
inputs  into  a  wide  variety  of  outputs.  These  outputs  con¬ 
sist  of  several  types.  Some  are  simple  internal  file  queues, 
printed  listings  and  reports  and  others  are  formatted  docu¬ 
ments,  as  in  reference  to  the  DD  1348-1  issue  documents 
utilized  for  material  distribution  purposes.  Additionally, 
the  MCS  had  adjunct  responsibilities  in  maintaining  the  BDP . 

This  section  on  the  MCS  will  identify  and  briefly  discuss 
major  Subsystem  II,  Module  II  program  interactions,  which 
produce  the  various  listings  and  modal  selections  related  to 
the  shipping  process.  The  MCS  is  the  source  of  many  decisions 
based  on  relating  the  NIIN  data  entity  to  attributes  of  the 
destination  UIC  data  entity.  The  MCS,  in  basic  terms,  uses 
the  character  data  elements  related  to  aspects  of  a  certain 
piece  of  material  and  makes  logical  decisions.  These  decisions 
are  based  on  restrictions,  regulations,  and  requirements 
attached  to  a  particular  shipment  or  Shipment  Unit  (SU)  as  they 
pertain  to  the  material's  destination  as  represented  by  the 
customer's  UIC.  Additionally,  the  MCS  utilizes  user  input 
issue  requisition  and  environmental  attributes  such  as  IPG 
and  issue  backlog  to  determine  workload  priority,  issue  and 


packing  priority,  shipment  consolidation,  and  certain  modal 
selections . 

The  following  is  a  partial  list  of  major  functions,  logi¬ 
cal  responsibilities,  and  decisions  that  NAVADS  Subsystem  II 
is  designed  to  perform: 

1.  Assign  Shipment  Control  Numbers  (SCN) 

2.  Generate  Workload  Reports  to  NISTARS 

3.  Provide  Documentation  Files  to  Subsystem  III 

4.  Selects  Shipping  Modes 

5.  Shipment  Consolidation 

6.  DD  1348-1  Issue  Document  Production 

7.  NAVADS  Exception  Listing 

8.  Planning  and  Warehouse  Area  Statistic  Reports 

9.  Air  Challenge  Listing 

10 .  AUTODIN  ATCMD  Data  Change  Operations 

A  management  feature  available  to  the  NAVADS  user, 
through  the  MCS ,  is  the  capability  to  suppress  the  release 
of  IPG  II  and  III  requisitions  from  the  NAVADS  Issue  File 
(NIF) .  The  NIF  is  a  holding  file  where  IPG  II  and  III  requi¬ 
sitions  are  held  for  later  issue  release  for  workload  or  ship¬ 
ment  planning  reasons.  The  NIF  uses  the  following  attributes 
as  release  controls;  "MARK  FOR"  UIC,  VJarehouse  Area  Code, 
Country  Code,  and  CONUS  Geographic  Area. 

Selection  for  release  of  IPG  II  and  III  requisitions  from 
the  NIF  can  be  done  using  the  following  record  attributes; 
"MARK  FOR"  UIC,  CONUS  Geographic  Sub-Area,  Issue  Priority 


Group,  Project  Code,  Warehouse  Area,  Country  Code,  CONUS 
Geographic  Area,  Water  Port  of  Embarkation  and  Water  Port  of 
Debarkation.  The  user  can  also  specify  which  UIC's  are  not 
eligible  for  consolidation. 

Once  selections  for  the  NIF  release  parameters  have 
been  made  and  UIC  consolidation  eligibility  has  been  deter¬ 
mined  this  program  will  then  consolidate  requisitions  into 
shipment  units.  The  program  first  makes  a  consolidation 
eligibility  appraisal  of  candidate  requisitions  for  a  parti¬ 
cular  shipment  unit.  When  the  appraisal  of  candidate  docu¬ 
ments  is  favorable  to  shipment  unit  formation,  a  Shipment 
Unit  Shipment  Control  Number  (SU,  SCN)  is  assigned  to  each 
shipment  unit.  The  eligibility  attributes  for  shipment  con¬ 
solidation  are: 

1.  UIC  is  eligible  or  is  designated  eligible  for 
consolidation 

2.  UIC  NFF  record  does  not  indicate  Local  Delivery 

3.  Document  number  is  not  a  bearer  walk-through 

4.  The  "MARK  FOR"  UIC's  are  the  same 

5.  Warehouse  Area  Codes  are  the  same 

6.  Item  is  not  sensitive,  hazardous  or  oversize 

7.  Weight/Cube  data  is  present  in  the  requisition  record 

8.  Weight/Cube  of  Shipment  Unit  exceeds  Parcel  Post 
requirements . 

When  the  Shipment  Unit  is  formed,  mode  selection  takes 
place  for  appropriate  surface  transportation  which  would  be 
either  "5"  (UPS),  "G"  (Surface  Parcel  Post),  "V"  (SEAVAN)  or 


"B"  (Less  Than  Truckload  (LTD.  Bearer  Wa  Ik -'"hroughs  are  "X"  , 
Local  Delivery  UIC's  are  mode  "9"  selected  and  units  that  con¬ 
tain  sensitive,  hazardous,  oversize,  or  dangerous  material  are 
coded  "Z"  or  break  bulk  select  in  accordance  with  mode  selec¬ 
tion  parameters  in  Table  5.  Consolidated  freight  is  assigned 
the  mode  indicated  in  the  Usual  Surface  Mode  (USM)  for  that 
Shipment  Unit  (SU)  UIC  as  it  appears  in  the  NNF . 

When  this  has  been  completed,  the  requisitions  are  re¬ 
leased  from  the  NIF,  the  corresponding  NXF  entries  are  also 
deleted  and  a  DOCID  "ZAU"  is  written  to  the  Physical  Inventory 
Queue  so  that  UADPS-SP  Physical  Inventory  updates  can  be  done. 

Subsystem  II  also  generates  a  series  of  seven  management 
reports,  designed  to  keep  physical  distribution  and  data  pro¬ 
cessing  managers  appraised  of  the  MCS ' s  activities.  These 
reports  are  listed  in  Table  6.  MCS  programs  utilized  for 
subsystem  operations  are  in  Appendix  A. 


IV.  subsystem  III 


A.  OVERVIEW 

This  chapter  will  concentrate  on  the  production  of  the  six 
basic  documents  produced  by  MAVADS;  DD  1387  Military  Shipping 
Labels,  Government  Bill  of  Lading  (GBL) ,  Commercial  Bill  of 
Lading  (CBL) ,  GBL/CBL  Continuation  Sheets,  Wotice  of  Availa¬ 
bility  (NOA)  DD  1348-5  and  TCMD/ATCMD,  in  both  the  hard  copy 
and  AUTODIN  options.  This  chapter  will  also  discuss  Subsystem 
Ill's  ability  to  solve  the  problems  involved  in  tracking 
requisitioned  material  through  the  stock  point.  Also,  brief¬ 
ly  discussed,  will  be  the  files,  programs  and  reports  utilized 
for  Module  IV,  Transshipment  Control.  A  summary  description 
of  the  Subsystem  III  programs  used  for  automated  document  pro¬ 
duction  are  in  Appendix  B. 

NAVADS  Subsystem  III  is  the  real  time,  m.inicom.puter  oper¬ 
ated  automated  documentation  system  composed  of  three  logical 
modules.  Modules  III,  IV  and  V.  Module  III  is  the  Automated 
Documentation  module  itself,  designed  to  alleviate  the  burden¬ 
some  task  of  physical  transportation  documentation  preparation 
Module  IV  is  the  Transshipment  Module  responsible  for  receiv¬ 
ing,  classifying,  documenting,  and  tracking  material  that  is 
passing  through  a  stock  point  from  an  outside  activity  to 
another  destination.  Module  V  is  the  Local  Delivery  module, 
originally  conceived  to  be  a  macro-automatic  vehicle  scheduler 
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and  local  load  planner  for  stock  point  deliveries  within  a 
designated  area  classified  as  local  for  a  particular  stock 
point . 

Subsystem  III  resides  on  Perkin-Elmer  series  32  mini¬ 
computers  at  the  various  NAVADS  sites.  In  the  Spring  of  1985, 
NSC  Jacksonville,  Florida  will  place  its  TANDEM-SPLICE  system 
into  operation,  replacing  the  Perkin-Elmer  minicomputer.  The 
TANDEM-SPLICE  system  will  eventually  be  installed  at  all 
naval  stock  points  equipped  with  NAVADS. 

Presently  the  Perkin-Elmer  system  uses  two  interface  com¬ 
munication  subroutines,  the  System  Communications  Data  Handler 
(SCDH)  to  receive  record  data  for  Subsystem  III  files  from 
the  Subsystem  II  files  and  the  INS  software  system  to  communi¬ 
cate  with  its  CRT's  for  document  processing.  TANDEM-SPLICE 
hardware  will  take  over  many  of  these  protocols  for  communica¬ 
tions  through  integrated  front-end  and  back-end  communications 
processing  with  the  different  Subsystems  and  their  hardware 
within  the  Local  Area  Network  (LAN) . 

Subsystem  III  performs  its  documentation  and  tracking 
duties  by  utilizing  a  series  of  nineteen  interactive  files 
which  draw  information  from  the  interactive  and  batch  files 
in  the  first  two  subsystems.  The  record  data  required  to 
maintain  these  files  are  provided  by  magnetic  tapes  or  hard¬ 
ware/program  queues  by  the  Management  Control  Subsystem. 

These  nineteen  interactive  files  provide  the  record  data  for 
twenty-six  printed  listings,  reports  and  documents  plus  a  wide 


variety  of  CRT  screen  image  formats,  used  for  inquiry,  display, 
changes,  additions,  and  deletions  of  record  data  regarding 
individual  shipping  unit  status,  location,  documentation, 
requisitions,  and  shipping  control  unit  formations.  A  list¬ 
ing  of  the  TAPS/DM  interactive  files  are  displayed  in  Table 
7.  The  Subsystem  III  reports  and  documentation  are  listed 
in  Table  8 . 

B.  BASIC  SHIPPING  DOCUMENTS 

The  DD  1387  Military  Shipping  Label  is  the  most  basic 
document  produced  by  Subsystem  III,  but  the  most  crucial 
since  it  provides  the  primary  routing  reference  for  transpor¬ 
tation  personnel  during  the  physical  handling  of  the  shipping 
unit  itself.  The  information  required  for  the  composition  of 
the  labels  are  contained  within  the  Shipment  Unit  Data  File 
(TAPS/DM  (002)).  There  are  two  different  sets  of  interactive 
programs  in  use  for  the  production  of  the  shipping  labels, 
the  NON-AIR  and  AIR  versions,  depending  on  the  shipment  mode 
assigned  to  a  particular  shipment  control  number.  An  example 
of  a  DD  1387  is  in  Table  9. 

The  Notice  of  Availability  (NOA)  DD  1348-5  is  an  automatic 
ally  produced  document  used  by  stock  points  to  notify  foreign 
country  representatives  and  applicable  freight  forwarders 
that  material  for  a  particular  country  is  available  for  ship¬ 
ment.  This  NOA  is  provided  for  material  from  either  the 
Security  Assistance  Program  or  the  Foreign  Military  Sales 
Program.  The  NOA  documentation  function  operates  through  the 


Shipment  Unit  Data  File  (TAPS/DJ-:  (0.0  2 ). )  and  the  Requisition 
Data  File  (TAPS/DM  (00.1). ).  for  record  information  and  processes 
it  through  three  Subsystem  III  programs;  V01230 ,  V012i0  and 
V^fl2  50.  An  example  of  a  NOA  is  in  Table  10.. 

Government  Bills  of  Lading  (GBL)  are  produced  by  Sub¬ 
system  III  to  document  and  provide  clearance  for  the  trans¬ 
portation  of  material  by  land  or  sea  routes  via  commercial 
carrier  in  a  limited  liability  environment  an  example  of  a 
GBL  is  in  Table  11.  It  is  a  primary  document  for  surface 
shipment  conforming  to  procedures  as  specified  in  NAVSUPINST 
4600.70  (series).  GBL  Front  Sheets  are  produced  through 
system  access  to  the  Transportation  Unit  Data  File  (TAPS/DM 
(003))  and  the  manipulation  of  data  in  this  file  by  programs, 
V03170,  V03240,  V03250  and  V03350. 

Commercial  Bills  of  Lading  (CBL)  are  contracts  between 
a  shipper  and  a  commercial  transporter  to  furnish  material 
movement  services  in  accordance  with  specific  commercial 
liability  limits  as  specified  by  the  standard  printed  clauses 
on  the  CBL  document  itself.  An  example  of  a  CBL  is  in  Table 
12.  The  CBL's  are  printed  using  data  within  the  (TAPS/DM (00 3 ) ) 
file  utilizing  Subsystem  III  programs  V03220,  V03300  and  V03310. 

GBL/CBL  Continuation  Sheets  hold  overflow  information  that 
cannot  be  held  on  the  front  sheet  of  a  Bill  of  Lading  alone. 
NAVADS  utilizes  a  single  common  program  to  handle  the  production 
of  standard  Continuation  Sheets  for  both  normal  GBL's  and  CBL's. 
This  common  program  is  (V03150) . 
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The  last  of  the  six  basic  transportation  documents  pro¬ 
duced  by  Subsystem  III  is  the  DD-1384  Transportation  Control 
and  Movement  Document  (TCMD)  as  shown  in  Table  14  and  Advanced 
Transportation  Control  and  Movement  Document  (ATCMD)  as  in 
Table  15.  These  documents  are  used  to  give  routine  or  ad¬ 
vanced  notification  of  a  shipment  to  an  Air  Clearance  Authori¬ 
ty  (ACA)  or  a  Water  Terminal  Clearance  Authority  (WTCA)  for 
shipments  going  to  an  air  or  water  Port  of  Embarkation.  The 
TCMD  can  also  be  used  as  a  manifest  for  actual  movement  or 
shipment  of  material.  The  subsystem  also  has  the  capability 
of  producing  and  transmitting  ATCMD ' s  card  images  via  AUTODIN 
to  the  NAVMTO  NATOS  system  for  Navy  and  Coast  Guard  shipments 
and  to  other  ACA's  and  WTCA's  for  other-service  ATCMD ' s  re¬ 
lated  requirements. 

TCMD  production  utilizes  the  TCMD  Image  Work  File 
(TAPS/DM (026) )  to  produce  the  required  hard  copy  and  AUTODIN 
card  images.  For  this  purpose  (TAPS/DM (026) )  uses  five  Sub¬ 
system  III  programs  V26010 ,  V26020,  V26040,  V26060  and  V26080. 
There  are  six  types  of  TCMD  headers  for  six  types  of  CRT  for¬ 
matted  workscreen  images.  The  type  of  TCMD  DOCID  header  is 
dependent  on  the  method  of  shipment  being  used  in  conjunction 
with  the  type  of  material  being  shipped.  Appropriate  TCMD 
DOCID  headers  are  cued  by  the  user  choice  of  an  interactive 
function  as  listed  here: 

1.  SUPODM  -  Prime  Shipment  Unit 

2.  SAEODA  -  Shipments  of  hazardous  material 
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3.  SUGWJl  -  Shipments  of  government  vehicles,  wheeled 

trucks,  guns  and  aircraft 

4 .  VENDSH  -  Vendor  shipments 

5.  LSULSM  -  Loose  shipment  units  in  SEAVANS  or  MILVANS 

6.  SUICSM  -  Shipment  Units  in  Consolidated  Containers 

loaded  in  SEAVANS  or  MILVANS . 

TCMS ' s  are  used  for  air  and  water  shipments,  ATCMD ' s  are 
used  for  air  shipments  going  to  Navy  and  Coast  Guard  units 
that  require  advance  notice  to  NAVMTO,  as  in  the  case  of  Mili¬ 
tary  Airlift  Command  (MAC)  mode  F  shipments.  Navy  and  Coast 
Guard  ATCMD ' s  use  the  Shipment  Unit  .Data  File  (TAPS/DM  (002) ) 
AIRINQ  function  for  this  purpose.  ATCMD ' s  for  other  services 
are  processed  through  (TAPS/DM (026) )  with  the  other  air  and 
surface  TCMS ' s . 

The  automated  composition  and  printing  of  the  six  basic 
documents  produced  by  the  NAVADS  system  lends  greater  accuracy 
to  document  production.  The  complex  and  detailed  composition 
of  the  documents  are  broken  down  to  simple  line  or  prompt 
entries  on  a  CRT  terminal  image  or  mask.  Routings,  endorse¬ 
ments,  and  printed  advisories,  required  by  regulation,  are 
automatically  applied  to  the  documents,  preventing  human  error 
or  mistaken  exclusion  of  a  requirement.  Shipment  Control  Num¬ 
bers,  GBL  Numbers  and  CBL  Numbers  are  all  assigned  automatic¬ 
ally  from  an  internal  queue  of  numbers  and  accounted  for  by 
the  system.  The  source  documentation  needed  to  make  up  the 
shipment  documents  are  available  from  the  automated  files 
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within  Subsystem  III  as.  consolidated  and  delivered  by  the 
Subsystem  II  Management  Control  Subsystem. 

C.  STOCK  POINT  MATERIAL  TRACKING 

An  additional  NAVADS '  capability  is  its  ability  to  keep 
track  of  requisitioned  material  as  it  passes  through  the 
stock  point  from  point  of  issue  to  point  of  shipment. 

Formerly,  stock  points  would  manually  issue,  pack,  move, 
and  ship  material,  using  locally  evolved  methods,  usually 
centering  around  the  collection  and  accumulation  of  DD-1348-1 
issue  document  controlled  materials  into  pallet  or  tri-wall 
units  for  shipment.  If  for  any  reason  a  particular  requisi¬ 
tion,  piece  of  material,  whole  pallet,  or  tri-wall  unit  had 
to  be  located,  stopped  or  retrieved  prior  to  shipment,  an 
extremely  labor  intensive  process  had  to  be  performed  first. 
This  involved  manually  accessing  the  issue  records,  the 
records  of  the  packing  area  (by  looking  through  tremendous 
piles  of  individual  DD-1348-1 ’s)  and  physically  tracing  the 
material  to  the  shipping  or  holding  warehouse.  An  experienced 
person,  with  good  luck  combined  with  practical  skill,  may  take 
a  whole  working  day  doing  this  kind  of  investigating  and 
retrieving . 

There  are  many  reasons  why  a  stock  point  may  want  to  track 
material  through  the  issue  process,  an  example  may  be  to  re¬ 
trieve  or  stop  a  piece  of  material  from  being  shipped. 


A  customer  may  have  ordered  a  part  or  material  on  an  IPG 
II  or  III  requisition  (medium  or  low  priority)  and  then  up¬ 
graded  the  requisition  priority  with  a  modifier  (AMI)  or 
message.  The  stock  point  may  find  that  surface  shipment  may 
not  conform  to  UMMIPS  time  frames  now  required  by  the  new 
priority.  Under  the  old  system,  the  part  may  have  just  been 
allowed  to  go  by  the  old  IPG  II  or  III  mode  of  shipment,  since 
tracing  the  material  down  may  have  taken  so  long  that  the 
effort  versus  potential  time  saved  may  not  have  been  worth  it. 
The  usual  answer  was  to  have  the  customer  initiate  a  whole 
new  requisition,  with  the  desired  higher  priority  resulting 
in  an  uneconomical  double  issue. 

With  NAVADS  a  requisition,  regardless  of  its  IPG,  is 
tracked  via  its  Requisition  Number  Shipment  Control  Number 
(REQ.SCN)  and/or  its  Shipment  Unit,  Shipment  Control  I3umber 
(SU.SCN)  from  point  of  issue  and  packing  to  its  staging  at 
the  shipment  bay. 

Subsystem  III  uses  its  Requisition  Shipment  Data  File 
(TAPS/DM (001) )  and  Shipment  Unit  Data  Files  (TAPS/DM (00 2 ) ) 
for  this  purpose. 

When  material  is  issued  either  from  bin,  NISTARS,  or  bulk, 
CRT  terminals  located  in  the  packing  areas  have  use  of  an  in¬ 
teractive  function  called  PCKUPD.  When  material  reaches  the 
packing  area,  a  clerk  or  CRT  operator  enters  the  REQ.SCN  and 
transmits.  When  this  occurs  the  file  (TAPS/DM (001) )  is  up¬ 
dated  for  that  REQ.SCN  showing  the  new  packing  area  location 
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entry  of  that  r.aterial  along  with  the  date.  When  the  material 
is  packed  it  is  forwarded  to  the  shipping  warehouse  for  stag¬ 
ing  and  pending  shipment.  VJhen  the  material  arrives  at  the 
warehouse  another  CRT  location  update  is  made.  By  this  time 
REQ.SCN's  that  have  been  mode  selected  for  freight  have  been 
consolidated  into  SU.SCN  record  groupings,  or  the  REQ.SCN  and 
the  SU.SCN  can  be  kept  one  in  the  same  for  material  selected 
for  Parcel  Post,  Mail  or  UPS  on  an  individual  basis.  This 
choice  of  transportation  mode  is  made  according  to  destina¬ 
tion,  priority,  size  and  characteristics  of  the  material  being 
shipped  (i.e.,  hazardous  or  sensitive).  The  warehouse  clerk, 
using  the  SU.SCN  as  a  reference  number,  calls  the  interactive 
function  FLRLUP  from  (TAPS/DM (002) )  and  enters  the  SU.SCN  and 
floor  location  in  the  shipping  area  of  the  material.  This 
does  two  things.  It  updates  the  shipping  unit  records  with 
the  location  of  the  material  and  flags  the  (TAPS/DM (002) )  file 
to  allow  production  of  the  GBL's  and/or  the  CBL ' s ,  since  now, 
the  material  is  ready  for  shipment  in  its  final  profile. 

Now,  if  a  customer  needs  to  get  to  a  piece  of  critical 
material  or  the  stock  point  wishes  to  stop  shipment  of  materia 
it  can  inquire  the  Subsystem  III  files  and  not  only  receive 
information  on  where  and  when  it  was  packed,  but  also  the 
location  of  the  material  in  the  shipping  warehouse  and  when  it 
got  there.  The  customer  services  personnel  can  "put  their 
finger"  on  the  material  in  minutes  rather  than  hours. 


Many  of  the  NAVADS  sites  have  their  shipping  areas  segre¬ 
gated  into  air^  overland  surface,  and  overocean  surface  sub- 
areas  to  make  physical  movement  and  distribution  easier.  The 
resulting  breakdown  to  unique  shipping  areas  and  dispersal 
of  material  into  these  less  dense  modules  is  not  a  problem 
for  NAVADS  to  handle  and  lends  itself  to  faster  and  easier 
location  of  material.  The  preparation  of  material  and  produc 
tion  of  the  required  shipping  documents  has  cut  down  dramatic 
ally  on  shipment  holds  in  warehouses  and  has  made  for  easier 
identification  and  location  of  special  interest  material  and 
shipments . 

D.  TRANSSHIPMENT  CONTROL  (MODULE  IV) 

One  of  the  most  difficult  problems  in  the  Naval  Supply 
System  is  tracing  or  following  material  going  from  point  of 
origin  to  point  of  destination  through  a  third  party.  Trans¬ 
shipments  were  often  treated  as  pariahs  within  tiie  world  of 
physical  distribution.  They  were  entities  for  which  no  one 
had  apparent  responsibility,  and  no  one  wanted  to  take  on  as 
a  responsibility.  The  difficulty  centered  on  priority,  docu¬ 
mentation,  accountability,  and  time.  Priority  for  a  stock 
point  usually  lies  with  the  issue  and  shipment  of  its  own 
requisitions  to  its  own  customers  within  prescribed  time 
frames.  Documentation  for  items  that  show  up  for  transship¬ 
ment  can  at  times  be  spotty  or  barely  readable.  Time  to  rees 
tablish  documentation  can  be  consuming  in  terms  of  manpower. 


Accountability  for  transshipment  can  be  almost  impossible  since 
audit  trails  for  transshipments  often  disappear  with  its  pri¬ 
ority  and  documentation.  The  result  of  all  this  is  valuable 
time  expended  in  manually  reestablishing  priority,  creating 
documentation,  and  reestablishing  the  audit  trail. 

NAVADS  assists  in  these  efforts  through  close  definition 

of  transshipments  and  by  creating  an  electronic,  automated 

pathway  allowing  the  material  to  pass  through  a  stock  point 

documented  for  later  tracing  if  required.  NSC  Oakland  (NSCO) 

handles  transshipment  in  the  following  manner  as  extracted 

from  the  NAVADS  Operator's  Handbook  [Ref.  5:p.  IX-1]. 

"For  NAVADS  purposes,  a  Transshipment  is  material  NOT 
resulting  from  a  stock  issue  AND  meeting  one  or  more 
of  the  following  criteria; 

a.  Destined  for  overseas  consignee; 

b.  Eligible  for  NAVMTO  Parcel  Post  forwarding  program  to 
PACO.M/CONUS  activities; 

c.  Eligible  for  delivery  via  Bay  Area  Local  Delivery  (BALD) , 
to  consignee; 

d.  Reparable  item  coming  from  Bldg  543  for  packing  and/or 
shipping  to  consignee  (a  designated  overhaul  point) . 

Direct  Turnover  (DTO)  items  received  for  NSC  Oakland  it¬ 
self  from  another  activity  is  not  considered  to  be  a 
transshipment . 

The  originator's  shipping  documents  can  also  take  many 
forms;  (Vendors  Shipping  Orders,  DD-1149,  DD-250,  DD-1348)  . 

In  order  to  track  material  transitting  the  Center  (NSCO) , 
transshipments  must  be  entered  into  the  NAVADS  systems  at 
the  point  of  entry  to  the  Center.  Once  entered,  transship¬ 
ments  are  processed  via  NAVADS  the  same  as  if  issued  and 
shipped  by  NSC  Oakland." 


Material  entering  a  particular  NAVADS  site  is  intercept¬ 


ed  directly  in  the  receiving  area.  A  CRT  terminal  in  the 
receiving  area  is  used  to  input  information  about  the  shipment 
from  the  available  accompanying  documentation.  The  operator 
uses  a  (TAPS/DM  (^01 )  ).  file  function  called  TRNSHP  and  is  cued 
by  the  CRT  to  make  certain  inputs  (minimum  entry  is  the  TCN) 
regarding  the  shipment  from  the  accompanying  documents.  The 
user  also  enters  the  location  of  the  warehouse  area  to  which 
the  material  is  being  sent  for  further  transfer  (Parcel  Post, 
UPS,  Surface  or  Overseas,  Air  or  Local  Delivery) .  In  this 
way  the  material  has  been  entered  into  the  system,  accounted 
for,  given  a  location,  and  placed  on  a  queue  for  shipment. 

Screen  016  of  (TAPS/DM (001) )  gives  the  user  a  record 
summary  of  the  just  entered  Shipping  Unit  being  transshipped. 
Records  for  transshipments  are  kept  for  180  days  on  the 
Transshipment  History  File  (TAPS/DM (023) ) .  This  file  allows 
users  to  have  an  audit  trail  on  a  real-time,  on-line  basis. 

The  transshipment  database  is  accessible  by  several  keys*. 

1.  DOC. NR.  Document  Number 

2.  TCN  Transportation  Control  Number 

3.  GBL.CBL.NR  Government  or  Commercial  Bill  of  Lading 

Number 

4.  SHIP.TO.UIC  Ship  to  Unit  Identification  Number 

Module  IV  interacts  with  Module  III  and  provides  the  same 
services  for  the  transshipped  material  once  inside  the  NAVADS 
arena  as  for  any  other  issued  material. 


f 


4] 


CURRENT  OPERATIONS  AND  ISSUES 


NAVADS  was  conceived  to  lessen  the  logical  and  manual  in¬ 
tensive  labor  of  Navy  Stock  Points  in  order  for  them  to  con¬ 
centrate  on  overall  concepts  of  physical  distribution  and 
material  management.  The  system  was  to  provide  a  level  of 
standardization  but  was  to  allow  enough  flexibility  and  data 
processing  environmental  control  so  that  individual  stock 
points/Naval  Supply  Centers  could  adapt  their  in-house  NAVADS 
system  to  conform  with  local  constraints  and  regulations . 
NAVADS-standardized  attributes  in  hardware  and  system  programm' 
ing  permits  the  central  file  maintenance  site  at  NSC  Norfolk 
and  the  appropriate  DLA  agencies  to  keep  all  Master  Stock  Item 
Records  (MSIR) ,  Unit  Identification  Codes  (UIC) ,  mechanized 
Management  Data  Lists  -  Navy  (MDL-N) ,  and  other  related  files 
for  National  Item  Identification  Number  (NIIN)  reference  up¬ 
dated  at  all  sites  at  all  times  with  little  or  no  hardware, 
software,  or  database  conversion  problems.  In  the  past,  local 
procedures  or  applications  of  hardware  and  software  facilities 
adapted  over  the  years,  allowed  the  supply  system  to  evolve 
into  a  disparate  collection  of  loosely  related  interfaced 
systems  rather  than  as  a  centrally  informed,  wholly  integrated 
world  wide  logistics  operating  complex. 

In  1978  the  Fleet  Material  Support  Office  (FMSO) ,  publish¬ 


ed  an  initial  NAVADS  Requirements  Statement,  emphasizing  the 


basic  need  and  justifications  for  a  minicomputer-operated, 
real-time/batch  system  to  take  over  the  duties  of  preparing 
documentation,  tracing  transshipments,  assisting  local  deliv¬ 
ery  operations,  and  automating  the  military  air  freight  system 
entry  procedures.  A  set  of  basic  assumptions  were  defined  in 
the  opening  statement  of  the  NAVADS  Requirements  Statement 
[Ref.  1 : p .  6 ] : 

1.  Most  modules  will  operate  on  a  stand  alone  minicom¬ 
puter  configuration  complete  with  random  access 
storage,  CRT  source  data  entry  I/O  (input/output) 
devices  and  other  peripheral  equipment  to  read, 
punch  cards  and  print  listings. 

2.  Application  software  will  be  programmable  in  COBOL. 

3.  A  COBOL  compiler  will  be  available  upon  delivery  of 
hardware . 

4.  A  test  bed  hardware  configuration  will  be  installed 
at  FMSO  in  time  to  support  application  program 
development . 

5.  A  hardware  interface  will  exist  between  the  NAVADS 
minicomputer  and  UADPS-SP. 

6.  The  local  delivery  scheduling  module  due  to  program 
size  and  complexity  may  have  to  run  on  the  Burroughs 
Medium  System. 

Of  course  many  of  the  early  assumptions  could  not  foresee 
future  changes  in  systems  loading,  technology,  and  other  in¬ 
novations.  A  sample  of  these  issues  facing  NAVADS  follows. 

A.  ECONOMIC  ANALYSIS 

The  FMSO  NAVADS  project  team  is  currently  preparing  to  en- 
gate  in  an  economic  evaluation  program  to  measure  the  aggre¬ 
gate  cost  and  benefits  obtained  from  the  automation  of 
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transportation  consolidation,  documentation,  and  tracking. 

The  evaluation  will  be  a  global  system  study  involving  all 
three  subsystems  and  five  imbedded  modules. 

Current  preliminary  plans  under  consideration  acknowledge 
the  need  to  adapt  Industrial  Engineering  (IE)  measurement 
methods  to  compare  the  actual  level  of  documentation  effort 
in  a  manual  system  versus  the  documentation  effort  within  the 
NAVADS  system.  This  effort  would  consist  of  passive  observa¬ 
tion  and  measurement  of  human  logic  and  labor  effort  (in  man¬ 
hours  per  shipping  unit  document)  in  the  preparation  of  the 
six  basic  transportation  documents; 

1.  DD  1387  Shipment  Labels 

2.  U.S.  Government  Bill  of  Lading  (GBL)  (SF  1103) 

3.  Commercial  Bill  of  Lading  (Local  Forms) 

4.  GBL/CBL  Common  Continuation  Sheet  (SF  1109). 

5.  Notice  of  Availability  (NOA)  (DD  1348-5) 

6.  Transportation  Control  and  Movement  Document  (TCMD) 
and  Advanced  TCMD  AUTODIN  formats  (DD  1384) 

As  stated  previously,  the  unit  of  measurement  could  be  a 
percentage  of  manhours  per  document  and/or  a  volume  per  person 
per  hour  rate.  This  would  be  used  to  formualte  a  non-auto- 
mated  work  standard  for  Naval  transportation  documentation  at 
a  typical  non-automated  site.  Once  this  has  been  accomplished 
measurement  can  then  be  taken  at  NAVADS  automated  sites  for 
cost-benefit  analysis  on  net  volume  of  documentation  produced 
(that  is,  gross  volume  minus  documents  returned  due  to  errors) 


The  dollar  cost  per  manhour  (HH).  saved  with  comparative  studies 
of  traffic  and  throughput  volume  of  the  system  paried  against 
cost  of  the  program  over  its  life  cycle  can  then  be  presented. 

NAVSUP  policy,  in  conjunction  with  other  federal  audit 
services,  requires  this  kind  of  detailed  cost-benefit  analysis 
in  order  to  measure  the  growing  trend  in  automation  costs  both 
of  hardware  and  software  as  compared  to  savings  obtained  in: 

1.  Operational  efficiency 

2.  Reduction  in  inventory  costs 

3.  Reduction  in  occurences  of  degraded  inventory  levels 

4.  Economic  goal  achievement  in  meeting  UM.MIPS  standards 

5.  Revision  of  End-Strength  (ES)  goals  in  savings,  both 
hard  and  potential . 

These  categories  of  savings  would  be  quantified  via  measure¬ 
ment  in  the  following  categories: 

1.  Material  Consolidation  Efforts 

a)  Pick  and  pack  process 

b)  Shipment  Unit  (SU)  formulation. 

2.  Personnel  Effort: 

a)  MH  spent  on  manual  techpub  look  ups 

b)  MH  spent  on  manual  material  searches 

c)  Savings  on  labor  intensive  functions  (clerical  and 
mechanical) . 

3.  Realignment  and  work  rule  savings  based  on  changes  that 
will  occur  in  productivity  due  to  automated  work  environ¬ 
ment  changes  caused  by  NAVADS  as  duties  evolve  away  from 
the  manual  environment  and  toward  the  automated  environment. 


46 


other  physical  distribution  measurement  factors  that  must 
be  considered  as  candidates  for  economic  quantification  vari¬ 


ables  at  NAVADS  sites  are: 


1. 

Geographic  restrictions  on  traffic  operations 

2. 

Receipt  and  issue  queuing  rates 

3. 

Daily  processing  and  backlog  rates  for  IPG  I, 
III  issues 

II, 

and 

4  . 

Operational  and  tactical  situational  changes 
fleet  movement,  war  damage,  etc.) 

(FAD 

changes 

5. 

Facilities  type  and  size  restrictions 

6  . 

Communications  environment  in  which  the  LAN  will 
operating . 

be 

Further  economic  analysis  variables  can  be  drawn  from  the 
analysis  of  the  causalities  of  economies  and  diseconomies  of 
scale  that  result  from  the  actual  installation  and  initial 
start  up  of  the  NAVADS  system,  such  as: 

1.  Training  curve  (including  OJT  time) 

2.  Learning  curve  (including  error  rates) 

3.  Usurption  of  routine 

4.  Physical  installation  (tear  down  and  build  up) 

5.  Cost  of  phase-in  operations. 

Presently  NAVSUP  and  FMSO  are  using  baseline  data  analysis 
techniques  developed  by  the  Navy  and  DOD .  Two  of  these  analy¬ 
sis  models  are  DIVS  (Defense  In-transit  Item  Visibility) ,  for 
the  measurement  of  dollar  savings  obtained  from  the  efficient 
cancellation  of  material  requests  before  funds  are  expended  on 
unnecessary  shipment,  and  VOSL  (Variable  Operating  and  Safety 
Level) ,  the  part  of  the  UADPS-SP  Retail  Inventory  Module  which 
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measures  the  cost  and  dollar  savings  which  are  effected  by 
efficient  and  standardized  methods  of  avoiding  requisition 
processing  delays.  These  models  provide  basic  data  in  terms 
of  volume  and  dollar  unit  savings  involved  in  shipping  con¬ 
solidations,  inventory  operations,  and  other  phases  of  the 
actual  physical  distribution  process. 

B.  ADA  IMPLICATIONS  FOR  NAVADS 

DOD  DIRECTIVE  5000.31  states:  "Effective  1  January  1984 
for  programs  entering  Advanced  Development  and  1  July  1984  for 
programs  entering  Full  Development,  ADA  shall  be  the  programm¬ 
ing  language." 

With  the  proliferation  of  so  many  different  computer 
systems  throughout  the  DOD  establishment,  it  was  inevitable 
that  a  commensurate,  prolific  growth  in  programming  languages 
would  occur.  It  was  not  unexpected  that  DOD  would  eventually 
end  this  electronic  "Tower  of  Babel"  by  exacting  efforts 
toward  standardization  of  coding  languages.  In  terms  of  stra¬ 
tegic  thinking,  what  are  the  implications  for  NAVADS?  Will 
NAVADS  find  itself  a  victim  of  the  DOD  evolutionary  process 
towards  language  standardization,  resulting  in  a  complete 
re-coding  from  the  present  languages  to  ADA?  Will  UADPS-SP 
and  NISTARS  also  be  forced  to  eventually  conform  as  more  and 
more  of  the  services  and  DOD  standardize?  It  may  not  be  enough 
to  just  merely  formulate  language  conversion  protocols  in  order 
to  be  able  to  interface  with  the  rest  of  the  DOD  establishment. 
This  is  an  eventuality  that  must  be  considered  now  and 
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subjected  to  detailed  study  for  determining  the  long  range 
implications  not  only  for  NAVADS,  but  for  UADPS-S?,  NIST?\PS 
and  other  SPLICE  programs. 

C.  DEPOT  LEVEL  REPAIRABLES  (DLR)  ISSUES 

DLR's  are  high  cost  repairable  spare  parts  serviced  at 
various  Naval  repair  facilities  for  re-use.  As  a  part  of  a 
test  started  in  April,  1981,  non-aviation  DLR's  were  reclassi¬ 
fied  and  financed  as  Navy  Stock  Fund  (NSF)  items.  Customers 
are  presently  charged  a  "net  price"  for  the  items  to  cover  the 
cost  of  transportation,  rework  and  item,  attrition.  A  "full 
price"  is  charged  for  the  item  if  no  turn-in  of  retrograde  is 
made.  The  DLR  program  is  expected  to  be  extended  to  aviation 
reparables  in  April,  1985.  What  implications  does  this  hold 
for  NAVADS?  Will  the  stock  points  be  tasked  for  transship¬ 
ment  status  of  NRFI  material  through  a  particular  NAVADS  site? 
Now  that  the  non-receipt  of  NRFI  material  at  a  depot  level 
activity  will  hold  serious  financial  implications  for  a  field 
level  activity,  do  NAVADS  sites  inherit  the  task  of  being  a 
universal  reference  point  or  clearing  house  for  missing  retro¬ 
grade?  When  aviation  repairables  go  into  stock  fund  status, 
the  volume  of  interest  in  tracking  retrograde  through  the 
system  will  increase  dramatically,  especially  for  stock  points 
located  in  the  vicinity  of  Naval  Air  Rework  Facilities  (NAP.F)  . 

It  may  be  necessary  to  treat  NRFI  items  in  the  transship¬ 
ment  module  (Module  IV)  as  special  case  items  requiring  their 
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own  TAPS  (DM)  interactive  file.  This  would  keep  thein  as  a 
special  class  of  transshipments.  This  segregation  would  make 
file  access  easier  for  retrograde  transshipment  inquiries 
since  sorting  through  transshipments  unrelated  to  retrograde 
movement  would  be  avoided. 

D.  SECURITY  AND  ADP  CONTINUITY 

In  view  of  contem.porary  events,  concerning  acts  of  terror 
ism  against  military  installations  at  home  and  abroad,  secur¬ 
ity  of  data  processing  equipment  and  records  is  increasingly 
becoming  of  great  concern.  The  Navy  Supply  System  has  become 
extremely  dependent  on  data  systems  as  can  be  seen  by  the 
extensive  data  file  and  operating  record  structures  of  ITAVADS 

OPNAVINST  5239.1  (series)  directs  Navy  efforts  for  ADP 
security  and  establishes  guidelines  in  providing  a  security 
framework  for  both  hardware  and  record  facilities. 

Towards  this  end,  the  security  of  NAVADS  must  be  looked 
at  in  two  ways:  the  first  is  the  security  needed  to  prevent 
unauthorized  scrutiny  and  m.anipulation  of  working  and  histori 
cal  files  within  the  three  NAVADS  subsystems.  The  second  is 
to  guarantee  secure,  alternate  facilities  for  NAVADS  process¬ 
ing  in  case  of  actual  hardware  damage  or  destruction  due  to 
acts  of  terrorism.,  war,  or  natural  disaster. 

Unauthorized  scrutiny  or  m.anipulation  of  files  from  a 
local  terminal  or  (after  initiation  of  SPLICE-DDN  operations) 
from  wide  area  network  term.inal  penetration  is  a  real  and 


potentially  dangerous  problem  facing  Navy  Stock  Points.  In 
NAVADS  several  files  contain  potentially  damaging  information 
that  could  possibly  be  used  to  track  general  locations  of 
ships,  aviation  squadrons,  afloat  staffs  and  other  mobile  com¬ 
bat  units.  Especially  vunerable  are  such  files  as  the  CRIF, 

NNF  and  related  air  and  water  transportation  clearance  and 
challenge  files  which  list  routing  codes  and  plain  language 
routing  addresses  for  various  customer  UIC's. 

The  second  area  of  security  concerns  the  advent  of  damage 
or  destruction  of  hardware  or  peripheral  devices  due  to  an 
act  of  terrorism,  war,  or  as  is  much  more  likely,  by  a  natural 
disaster.  NAVADS  sites  are  integral  parts  of  larger  Navy  com.- 
plexes,  such  as  operating  bases,  air  stations,  rework  facili¬ 
ties  or  shipyards.  Their  natural  proxim.ity  to  their  largest 
customers,  by  definition,  place  them  in  potential  harm's  way. 

As  NAVADS  develops  and  becomes  increasingly  im.bedded  within 
naval  operations,  the  consequences  of  physical  damage  increases. 
Whether  this  damage  is  caused  by  climatic,  geological  or  poli¬ 
tically  motivated  acts  is  irrelevant,  the  end  results  are  still 
the  same;  downtime,  lost  data,  lost  records  and  in  increasing 
probability  that  total  recoverability  will  not  be  achieved 
over  time. 

E.  LOCAL  DELIVERY  ISSUES 

Much  of  the  effort,  since  the  inception  of  NAVADS,  has 
been  to  utilize  the  Subsystem.  Ill,  Module  V  portion  of  the 
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system  as  an  Automatic  Vehicle  Scheduler  (A.VS)  for  use  in 
planning  local  delivery  routes  and  scheduling.  "^he  AVS  con¬ 
cept  is  presently  under  research  at  the  David  Taylor  Naval 
Ship  Research  and  Development  Center  in  cooperation  with  tests 
being  conducted  at  NSC  Charleston,  SC. 

At  this  writing,  Module  V  is  not  in  active  use  at  any  of 
the  NAVADS  sites  since  it  is  still  under  development. 

Module  V  was  conceived  to  be  two  distinct  operations;  one 
system  to  move  material  from  one  activity  to  another  (i.e., 

NSC  to  a  docked  ship,  NARF,  or  NSY) :  and  the  other  system  to 
move  material  around  within  an  activity  (i.e.,  from  packing 
area  to  warehouse  area  within  an  NSC  compound) . 

Material  to  be  moved  from  one  activity  to  another  is  split 
into  two  sub-activities,  AVS  I  and  AVS  II.  AVS  I  is  used  for 
scheduling  routine  deliveries  to  various  activities.  AVS  II 
is  used  to  provide  for  emergency  issue  deliveries  and  pick  ups 
of  material. 

Within  Subsystem  III  there  are  two  major  reports  v;hich 
are  used  to  list  shipments  available  for  local  delivery. 

These  are  the  Shipment  Scheduled  for  Local  Delivery  (On-Line) 
and  Shipments  Scheduled  for  Local  Delivery  (Batch)  .  These  pro¬ 
grams  list  the  shipments  available  for  local  delivery  by  keyina 
on  local  area  UIC's  and  providing  relevant  delivery  in¬ 
formations:  REQ.SCN,  PROJ  CODE,  RDD ,  Date  to  Packing,  Pack 

Location,  Est.  Weight  and  Cube.  Susbvstem  III  Programs  Vfifll90 
(On-Line)  and  VLOCDL  (Batch)  obtain  inform.ation  for  its 


reports  from  the  (TAPS/DM (001) )  file  and  reports  all  requisi¬ 
tions  with  modes  "X"  or  "9"  that  do  not  have  a  proof  of  ship¬ 
ment  flag. 

Local  delivery  vehicular  scheduling  is  still  done  today 
on  a  manual  basis  by  a  delivery  dispatcher  with  little  or  no 
automated  assistance.  .Module  V,  if  used  as  originally  en¬ 
visioned  as  an  AVS,  will  allow  the  user-dispatcher  to  plan 
deliveries  according  to  a  listing  of  activity  UIC's  with 
material  available  for  delivery  and  of  vehicles  capable  of 
delivering  the  material  staged  for  local  delivery. 

On  the  whole,  vehicular  scheduling  is  extremely  dependent 
on  local  conditions  or  regional  environment.  It  is  far  too 
area  specialized  to  attempt  a  standardization  of  decision 
making  by  use  of  packaged  vehicle  placement  and  scheduling 
systems . 

Most  decisions,  made  on  an  hour  to  hour  basis  by  local 
dispatchers,  are  highly  dependent  on  many  human  variables 
that  may  not  be  manageable  by  strict  adherence  to  a  machine 
generated  framework  of  operating  patterns.  Vehicular  availa¬ 
bility,  accidents,  breakdowns,  personnel  deficiencies  (fore¬ 
seen  and  unforeseen) ,  and  so  on  make  vehicle  and  delivery 
scheduling  matching  an  almost  "ad  hoc"  affair,  based  totally 
on  human  initiative  and  decision  making. 

F.  SPLICE  QT’EPJXTIONS  WITHIN  N.AVADS 

NAVADS  v/ill  operate  within  a  communications  protocol 
called  the  Stock  Point  Logistics  Integrated  Communications 
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Environment  (SPLICE) .  The  SPLICE  minicomputer  will  act  as 
the  front  end  communications  processor  for  the  Burroughs 
Medium  System  which  will  maintain  and  structure  the  stock 
point  basic  data  package.  Dr.  Norman  Schneidewind  states 
[Ref.  6:p.  22]: 

"Two  major  objectives  led  to  the  development  of  SPLICE; 
first;  the  increased  need  for  the  use  of  interactive  data 
base  processing  to  replace  the  current  batch-oriented 
system;  second,  the  need  to  standardize  the  current 
multitude  of  interfaces." 

The  Burroughs  Medium  System  (UADPS-SP)  will  also  interface 
with  AUTODIN  (to  eventually  be  superceded  by  the  Defense  Data 
Network  (DDN)  upon  full  implementation  of  SPLICE)  to  process 
incoming  requisitions  from  other  DOD  activities.  Additionally 
it  will  update  the  data  files,  send  the  lequired  data  elements 
for  the  formulation  of  workload  reports  and  shipping  require¬ 
ments  to  NAVADS ,  and  pass  the  material  issue  and  packing  or¬ 
ders  to  the  NISTARS  system. 

A  present  difficulty  with  NAVADS,  as  it  presently  operates, 
centers  around  the  access  time  anomalies  that  occur  v/hen  a 
real-time  system  is  placed  in  an  interface-dependent  relation¬ 
ship  with  a  system  that  is  batch-oriented.  The  original  spec¬ 
ifications  for  NAVADS  required  a  three  to  five  second  response 
time  for  CRT  operations.  Screen  response  times,  at  peak  loads, 
have  been  timed  from  twenty  seconds  to  as  much  as  forty  sec¬ 
onds  depending  on  the  type  of  file  manipulation  requested. 

One  cause  is  that  file  structures  going  through  the  look-ahead 
software  feature  must  be  accessed  twice  for  each  transaction. 
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This  feature  had  been  installed  to  protect  master  files  from 
being  altered,  damaged,  or  segmented  during  the  accessing 
process.  The  first  access  is  used  for  record  retrieval,  es¬ 
tablishing  file  locks,  and  performing  file  integrity  checks. 
The  second  access  is  used  to  perform,  the  actual  transactions. 
Between  file  accessing  for  inquiries,  changes,  additions,  and 
local  and  master  file  updates  a  condition  called  "thrashing" 
can  occur.  Consequently,  accounting  for  NAVADS '  twenty-three 
master  files  and  forty-two  index  keys,  it  is  easy  to  see  why 
thrashing  can  occur,  particularly  when  all  key  files  that 
have  been  called  or  modified  in  some  way  must  be  re-collated 
in  order  to  put  the  new  or  modified  file  back  in  place.  All 
this  must  be  accomplished  before  a  new  transaction  can  be 
processed.  This  is  a  primary  area  of  conflict  where  real-tim.e 
access  capability  conflicts  with  inverted  list  data  and  file 
structures  which  require  sort  and  re-sort  protocols . 

With  the  introduction  of  TAPS  II,  and  its  ability  to  in¬ 
tegrate  data,  this  problem  may  be  reduced.  However,  so  long 
as  NAVADS-SPLICE  and  NISTARS-TANDEM  are  required  to  interact 
with  a  batch  oriented  mainframe  system,  processing  will  con¬ 
tinue  to  be  only  as  fast  as  the  slowest  machine.  The  sort 
protocols  and  key  access  schemes  will  eventually  lead  to 
saturation  of  hardware  memory  and  storage  assets.  To  solve 
this  dilema  UADPS-SP  should  be  prioritized  for  replacement  by 
a  real-time,  on-line  hardware  system  that  is  fully  compatible 
to  the  TANDEM  systems  installed  for  NAVADS-SPLICE  and  NISTARS . 


G.  TERMINAL  APPLICATION  PROCESSING  SYSTEM  (TAPS) 

TAPS  is  a  proprietary  software  system  resident  within  the 
Subsystem  III  hardware  responsible  for  Module  III,  IV,  and  V 
operations.  Its  function  is  to  act  as  a  database  manager  and 
data  manipulator  for  those  files  accessed  from  the  Burroughs 
Medium  System  -  Subsystem  II,  Module  II  operation.  TA^S ,  as 
well,  is  responsible  for  the  real  time,  on  line  operation  of 
the  NAVADS  terminals.  There  are  3  major  management  modules 
within  the  TAPS  framev/ork. 

TAPS  (AM)  -  is  the  Applications  Management  module,  which 
extracts  input  data  from  off  the  CRT  screen  format  images, 
validates  the  data  for  correctness  and  completion  and  forwards 
the  data  to  the  TAPS  (DM)  module. 

TAPS  (CM)  -  is  a  multi  function  Communications  Management 
module  which  monitors  terminal  traffic  and  throughput  and 
operates  the  I/O  polling  of  the  LAN  CRT's  within  NAVADS.  TAPS 
(CM)  interfaces  with  the  INS  software  system  which  provides  a 
logical  multidrop  network  environment  to  overcome  hardware 
connection  limitations.  All  terminals  interface  with  the 
TAPS  (CM)  module  only  through  the  INS  software. 

TAPS  (DM)  -  is  the  Data  Management  system  (resident  DBMS) 
utilized  to  both  manage  and  manipulate  data  called  in  from  a 
file  queue  provided  by  the  Management  Control  System.  Entry 
into  the  Subsystem  I,  Module  I  database  is  done  by  Subsystem 
II,  Module  II  via  VISAM  (Variable  Index  Sequential  Access 
Method)  which  uses  an  index  key  access  system  to  enter  the 


database  and  construct  the  required  records  or  inquiries  into 
structured,  logical  files.  The  structured  logical  file  is 
then  drawn  from  Subsystem  II  into  Subsystem  III  by  the  TAPS 
(DM)  file  system  and  accessed,  m.anipulated ,  or  changed  in 
accordance  with  the  protocol  or  sub  program  call  requested. 

In  the  pre-SPLICE  environment,  operations  are  conducted 
on  a  Perkin-Elmer  mainframe  for  all  Subsystem  III  related 
processing.  TAPS  (or  TAPS  I)  operates  the  peripherals  and 
manipulates  the  required  files  for  Module  III,  IV  and  V 
operations . 

In  the  eventual,  final  configuration,  with  NAVADS  inte¬ 
grated  into  the  SPLICE  Local  Area  Network  (LAN) ,  which  is 
resident  within  the  Tandem  hardware  system,  the  TAPS  I  system 
will  be  replaced  by  the  TAPS  II.  TAPS  II  is  primarily  de¬ 
signed  for  operation  on  a  TANDEM  system  and  engineered  to 
interface  with  the  TANDEM  native  imbedded  GUARDIAN/ENSCRIBE 
database  management  system  (DBMS) .  TAPS  II  is  designed  to  be 
a  fully  portable,  machine  to  machine  software  system,  written 
in  a  High  Order  Language  (HOL)  for  versatility,  in  this  case 
PASCAL. 

TAPS  I  is  a  more  machine-esoteric,  dependent  software 
system,  written  in  Assembly  Language  and  adapted  over  to  the 
Perkin-Elmer  operating  system.  A  generalized  software  system, 
machine  independent  and  written  in  an  HOL,  such  as  TAPS  II, 
lends  a  greater  degree  of  failsoft  capabilities  and  post  fail¬ 
ure  recoverability.  As  well,  maintenance  on  the  software  is 
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easier  and  updates  tend  towards  faster  d i ssemina t ion  and  im¬ 
plementation  because  of  the  level  of  standardization  inherent 
in  generalized  software  operations.  Software  main t ai nabi 1 i tv 
is  fast  becoming  a  closely  scrutinized  area  of  ADP  development 
by  audit  and  oversight  agencies,  since  software  maintenance 
accounts  for  over  seventy  per  cent  of  all  life  cycle  manage¬ 
ment  costs  for  a  typical  ADP  project. 


VI .  SURVEY  OF  CIVILIAN  EXPRESS  CARRIER  ADP  METHODS 

NAVADS  operates  within  the  military  operating  environment. 
Efficiency  and  end  strength  savings  in  personnel,  administra¬ 
tive  costs,  and  effectiveness  are  its  primary  measurement 
parameters.  Conforming  to  UMMIPS  timeframes  and  MILS'^A.MP/MIL- 
STRIP  mandates  are  other  substantive  measurements  in  deter¬ 
mining  the  system's  worth  to  the  naval  logistics  establishment 

In  recent  times  the  civilian  business  corrimunity  has  also 
demanded  a  system  of  freight  and  sm.all  package  express  deliv¬ 
ery.  This  is  an  outgrowth  from  businesses  recognizing  that 
their  responsibilities  are  rising  commensurately  with  fiscal 
competition.  This  makes  communications  and  delivery  of  busi¬ 
ness  related  material  or  inventory  to  customers  important  in 
terms  of  temporal  timeframes. 

Several  major,  civilian  freight  express  corporations  have 
become  industry  leaders  in  providing  freight  and  small  pack¬ 
age  (or  packet)  overnight  delivery  services.  One  can  draw 
significant  parallels  between  their  operations  and  the  opera¬ 
tions  of  Navy  Stock  Points.  Approximately  seventy  per  cent 
of  all  issues  and  shipments  from  an  NSC  can  be  classified  as 
small  packages  (or  packets)  designated  for  local  delivery, 

UPS,  Parcel  Post  or  bulk  Mail  delivery.  Since  express  com¬ 
panies  must  measure  their  efficiency  and  efficacy  in  terms  of" 
profit  and  loss  statements  and  balance  sheets,  it  is  within 
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their  critical  interests  to  reduce  costly,  manual  labor  and 
logic  intensive  operations.  To  accomplish  this  they  have 
turned  to  the  use  of  automated  transportation  systems  to  re¬ 
ceive,  consolidate,  track,  route,  and  ship  packages  placed 
into  their  responsibility. 

A  brief  review  of  the  ADP  structure  and  operations  of  a 
civilian  express  firm  follows.  Comparisons  to  the  ADP  opera¬ 
tions  and  structures  of  the  NAVADS  system  at  Navy  Stock  Points 
with  the  civilian  firm  may  provide  a  valuable  insight  into 
performance  m.ethods  . 

A.  AIRBORNE  FREIGHT  CORPORATION 

The  AIRBORNE  FREIGHT  CORPORATION  of  Seattle,  Washington, 
utilizes  a  transportation  control  system,  called  FREIGHT  ON-LINE 
CONTROL  AND  UPDATE  SYSTEM  (FOCUS) .  FOCUS  operates  on  dedicated 
IBM  3083  MVS/SN/CICS  hardware,  using  an  IBM  3705  NCP/EP  com¬ 
munications  processor  linked  to  modems  with  signals  sent  out 
over  a  leased  line  network  and  a  number  of  "IN-V7ATS"  lines. 
Terminals  in  the  system  are  IBM  3270  BSC's  but  the  system  has 
multiple  protocol  capabilities  for  terminal  operations  via 
Personal  Computers  (PC) ,  IBM  2780  BSC  access  and  a  variety  of 
message  switching  operations.  Storage  for  on-line  operations 
is  accomplished  on  IBM  3380  disc  drives  as  per  the  AIRBORNE 
hardware  documentation  [Ref.  7]. 

AIRBORNE  uses  a  26  function  Shipment  Life  Cycle  (SLC) , 
consisting  of  12  outbound  material  functions,  and  14  inbound 


material  functions.  With  this  SLC,  AIRBORNE  ensures  that  the 
manual  functions  connected  with  the  pick-up,  transfer,  ship¬ 
ment,  and  delivery  of  freight  is  properly  documented,  account¬ 
ed  for,  and  input  into  the  FOCUS  system. 

At  AIRBORNE  each  AIRBORNE  AIRBILL  is  assigned  to  a  con¬ 
solidation.  These  consolidations  or  groups  of  AIRBORNE  AIR¬ 
BILLS  are  called  AIRLINE  AIRBILLS.  This  airbill  package  is 
referred  to  as  a  "consol",  this  is  similar  to  NAVADS '  consoli¬ 
dating  the  individual  REQ.SCN's  into  SU.SCN's. 

The  AIRBORNE  AIRBILLS  are  read  into  FOCUS  via  the  on-line 
entry  transaction  ARBE .  ARBE  is  the  initial  entry  transaction 
performed  on  material  to  "bring  it  onboard"  the  system.  ARBE 
creates  the  AIRLINE  AIRBILL,  performs  AIRBORNE  AIRBILL  trans¬ 
fers,  accesses  in  the  clear  customer's  name  and  address  from 
a  key  code  (much  like  the  UIC  relationship  to  the  MNF  in  NAVADS) 
ARBE  also  calculates  charges  and  flight  weights,  generates 
messages  and  appends  AIRLINE  and  AIRBORNE  AIRBILLS  to  the  ZIP 
CODE  ROUTING  SUBSYSTEM  (ZCRS) . 

The  Shipment  Tracking  feature  of  FOCUS  has  6  interactive 
transaction  functions,  as  per  the  AIRBORNE  software 
documentation  [Ref.  8]. 

ARBE  -  as  discussed  above  is  the  initial  entry  interactive 
routine  for  new  shipments  entering  the  SLC. 

ABTD  -  Airbill  Tracing  Display — here  the  user  inputs  the 
airbill  number  and  shipment  origin;  system  display  returns 
shipper,  consignee  and  third  party  name  and  address  infor¬ 
mation  as  well  as  shipment  movement  and  delivery  information. 


ABCD  -  Airbill  Charges  Display--here  the  user  inputs  the 
airbill  number  and  shipment  origin,  system  display  returns 
shipper,  consignee  and  third  party  /lame  and  address  infor¬ 
mation  along  with  charges  for  the  shipment. 

CNDP  -  Consol  Display--here  the  user  inputs  the  airline 
code  number,  origin  and  AIRLINE  AIRBILL  number;  system 
display  returns  all  information  concerning  a  particular 
consolidation,  including  flight  information  and  the  air¬ 
bill  keys  for  each  AIRBORNE  AIRBILL  in  the  consolidation. 

CNRD  -  Consol  Reference  Display--does  the  same  as  CNDP, 
but  here  the  user  can  opt  for  an  ABTD  or  ABCD  transaction 
inquiry  response  for  information  on  that  consol. 

CUST  -  Customer  Number  Display--here  the  user  inputs  a 
customer's  account  number  and  is  hown  a  list  of  shipments 
for  that  customer.  The  user  can  then  request  ABTD  or  ABCD 
information  on  those  shipments. 

Updates  to  master  on-line  records  are  done  from  log-files 
which  are  created  after  an  update  action  on  a  record.  These 
log-files  are  extracted  4  times  daily  from  the  system  and 
loaded  to  a  master  tape  file.  This  information  is  processed 
and  the  results  are  fed  back  to  the  on-line  systems.  The 
following  transactions  are  used  to  perform,  the  updates  on 
those  extracts,  resulting  in  the  processed  information  return¬ 
ing  to  the  system. 

CNAU  -  Customer  Name  and  Address  Update--customer  nu.mbers 
are  assigned  to  shippers,  consignees  and  "bill  to"  parties 
that  previously  had  no  customer  numbers  or  key  codes 
assigned  to  them  and  were  therefore  keyed  as  exceptional 
and  extracted. 

.MWAC  -  AIRBORNE  EXPRESS  Airline  Costing--all  consolidations 
for  AIRBORNE  EXPRESS  are  processed  here  to  calculate  air¬ 
line  cost  for  each  consolidation.  These  updated  consoli¬ 
dation  costs  are  returned  to  the  on-line  system. 

CINV  -  Centralized  Invoice  Pricing--when  the  airbill  and 
the  "bill  to"  party  has  its  customer  number,  the  invoice 
is  printed  here  by  this  routine.  The  on-line  files  are 
updated  with  the  print  date  and  time  of  the  invoice  print. 
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OLAC  -  On  line  Accounting — consol  dates  that  have  been 
passed  onto  accounting  have  the  accounting  date  applied 
here . 

OLFP  -  On-line  File  Purge--this  function  reviews  all 
candidate  records  for  purging  and  then  performs  the 
actual  purge  operation. 

The  database  structure  for  AIRBORNE  is  the  result  of  AIR¬ 
BORNE  '  s  committment  to  Data  Base  Technology.  The  database, 
using  IBM's  Data  Base  Management  System,  was  phased  in  grad¬ 
ually.  The  previously  used  BDAM  (Basic  Direct  Access  Method) 
was  phased  out  altogether  as  the  IMS  database  environment  took 
over  all  field  operations  and  supervision  of  AIRBORNE 's  43 
production  databases.  The  database  disc  utilization  struc¬ 
ture  for  the  IBM  3380 's  as  projected  for  .March  1984  are  in 
Table  16. 

B.  COMPARATIVE  VIEW 

Unlike  the  NAVADS  sites,  civilian  express  companies  lim.it 
what  they  can  accept  as  deliverable  material.  These  restric¬ 
tions  usually  center  on  girth  dimensions,  weight,  and  whether 
or  not  the  destination  is  within  one  of  their  covered  delivery 
areas.  NAVADS  stock  points  are  faced  with  a  variety  of  bulk, 
oversized,  hazardous,  and  security  sensitive  materials  that 
may  have  a  potential  delivery  point  anywhere  in  the  world 
where  there  is  a  potential  military  demand. 

Additionally,  a  civilian  express  firm  is  not  limited  in 
its  ADP  acquisition  process  by  the  constraints  imposed  by 
Acts  of  Congress.  Life  cycle  management,  as  well  as  develop¬ 
ment  life  cycle  reporting,  is  limited  only  by  the  rules  and 


procedures  set  down  by  the  individual  information  systems  or 
data  processing  departments  within  the  organization's  own 
hierarchy.  In  the  Navy,  as  well  as  throughout  the  Federal 
Government,  all  hardware  and  major  software  acquisition  is 
governed  by  the  recently  adopted  Federal  Acquisition  Regula¬ 
tions  (FAR) .  This  compendium  of  regulations  governs  all  as¬ 
pects  of  the  life  cycle,  development  cycle,  and  contractual 
processes  in  requesting,  awarding,  implementing ,  and  install¬ 
ing  new  ADP  systems. 

In  operation,  the  commonality  in  the  formation  of  AIRBORNE 
"consols"  and  NAVADS  Shipment  Units  is  striking.  NAVADS  has 
the  advantage,  however,  in  the  variety  of  shipment  modes  that 
can  be  selected  commensurate  with  the  Issue  Priority  Group 
(IPS)  required  by  the  customer.  AIRBORNE  relies  heavily  on 
organic  high  cost,  self-operated  air  and  overland  surface 
modes  and  on  contractual  air  freight  arrangements  with  other 
commercial  airline  operations.  There  is  no  priority  selection 
option,  it  is  assumed  that  if  AIRBORNE  was  called,  then  ship¬ 
ment  is  of  a  "Priority  One"  nature.  This,  of  course,  gene¬ 
rates  a  consistent,  high  cost  per  movement-unit  overhead, 
making  missed  or  lost  shipments  extremely  costly. 

NAVADS,  unlike  its  civilian  counterparts  in  private  indus¬ 
try,  has  extensive  collateral  duties  involved  in  inventory 
records  keeping  and  issue  control  with  U.ADPS-SP  and  NTS'^APS. 
/AIRBORNE 's  system  and  sim.ilar  other  systems  are  only  responsi¬ 
ble  for  freight  tracking,  documentation  and  shipment. 
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VII.  CONCLUSIONS  AND  RECONCIENDATIONS 


A.  OVERVIEV: 

NAVADS  is  a  positive  step  by  the  Navy  to  take  acivantage  of 
the  trends  in  data  processing  technology.  Real  time  opera¬ 
tions,  system  transparency,  and  user-friendly  designed  svstems 
are  slowly  superceding  the  older  batch  and  card  centere-'^  meth¬ 
ods  of  accomplishing  logistics  manaaement . 

NAVADS,  through  the  auspices  of  SPLICE,  will  soon  allow 
greater  flexibility  in  communications  as  it  brings  the  ''av'al 
Supply  System  closer  to  achieving  access  to  the  Defense  Data 
Network  (DDN) ,  eventually  phasing  out  the  need  for  dependence 
on  the  older  AUTODIN  network.  It  will  free  up  main  system 
assets  by  providing  for  front-end  and  back-end  communications 
processing  and  protocol  management  for  real  time  updates  and 
other  point-to-point  communications. 

This  system  will  allow  users,  managers  and  planners  to 
concentrate  on  the  management  of  exception  transactions  and 
to  leave  the  vast  portion  of  transactions  which  are  routine 
to  the  system. 

3.  LOCAL  DELIVERY  (MODULE  V)  ALTERNATIVES 

Module  V  may  be  best  put  to  use  not  as  a  local  d.elivery 
scheduler,  but  as  an  automated  documentation  module  for  local 
deliveries  in  order  to  relieve  Module  III  of  some  of  the 
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burden  of  tracking,  docunenting,  and  establishing  POS  certi¬ 
fications  for  all  outgoing  material.  It  rcav  be  of  long  terrr. 
benefit  to  allow  Subsysteir.  II  to  turn  cyer  all  consolidated 
shipments  v/ith  Shipment  Modes  of  "X"  (Bearer-l'.’alk  T’hroughs) 
and  "9"  (Local  Delivery)  to  Module  V.  After  release  of  the 
selected  requisitions  from  the  MIF,  Subsystem  II  would  con¬ 
solidate  the  shipments,  assign  the  REQ.SCN  numbers,  and  select 
the  mode  of  shipment.  Pick  and  packing  procedures  would  occur 
as  with  any  other  issue  of  material.  If,  however,  the  mater¬ 
ial  being  readied  for  shipment  has  a  Shipment  Mode  of  "9", 
the  PvEQ.SCN  records  would  be  shifted  to  M.odule  V  for  further 
consolidation  into  SU.SCN's  by  local  activity  UIC  groupings. 
After  the  PvEQ.SCM's  have  been  consolidated  into  SU.SCM's  by 
UIC  the  material  shipment  would  leave  packing  and  go  to  the 
local  delivery  shipping  warehouse,  where,  like  other  pieces 
of  freight,  a  shipping  floor  location  update  would  be  perform¬ 
ed.  L’hen  this  is  done  and  all  corrections,  additions,  and 
deletions  have  been  made.  Module  V  would  then  automatically 
produce  an  LEL  (Local  Bill  of  Lading)  on  the  shipping  floor. 
The  LBL  (a  DD-1149m)  would  list  a  "MARK  FOR"  address  and  list 
each  document  and  REQ.SCM  included  in  that  particular  local 
shipment  unit  for  that  activity.  The  LEL  production  procram, 
would  then  automatically  update  the  Proof  of  Shipment  (POS) 
file  and  update  the  historical  files  indicating  that  tlie 
material  was  shipped  and  that  the  record  is  closed. 


REMOTE  ACCESS  SURVIVA3LE  PROCESSING  (RASP) 


C  . 

The  first  area  of  concern  regarding  unauthorized  scrutiny 
of  the  NAVADS  files  can  be  dealt  with  by  initiating  various 
security  methods  to  ensure  secure  use.  These  methods  can 
include  measures  such  as  encryption,  restricted  use  terminals, 
or  queue  delaying  requests  for  itnerception ,  inspection  and 
clearance  of  requesting  access  terminals,  users  or  nodes. 

Various  methodologies  are  available  and  should  be  studied  for 
the  protection  of  system  information.  These  precautions  would 
be  in  addition  to  the  present  user  access  codes,  pass'vords,  and 
identification  methods  imbedded  within  the  TAPS  (CM)  system. 

The  second  area  of  security  regarding  the  potential  for 
damage  or  destruction  of  hardware  or  peripheral  devices  due 
to  an  act  of  terrorism,  war,  or,  as  is  much  more  likely,  a 
natural  disaster  is  a  real-world  concern  for  large  ADP  opera¬ 
tions  such  as  NAVADS. 

To  solve  this  matter,  the  NAVADS  program  should  consider 
an  additional  two  NAVADS--full  up  sites  beyond  the  sites  being 
developed  for  the  NSC's.  The  two  sites  would  be  split;  one 
western  site  to  provide  redundant  services  for  NSC  Puget  Sound, 
NSC  Oakland  and  NSC  San  Diego;  and  another  site  for  eastern 
operations  for  NSC  Norfolk,  NSC  Charleston  and  NSC  Jacksonville. 
The  RASP  sites  would  provide  back-up  processing  services  for 
the  stock  points  for  periods  of  extended  emergent  and  non- 
emergent  downtime  periods. 


These  RASP  sites  would  b.e  located  in  remote,  low  profile, 
geologically,  and  politically  stable  areas.  Urban  areas  and 
regions  with  military  establishments  would  be  avoided.  The 
RASP  sites  would  be  provided  with  TANDEM-SPLICE  hardware  for 
SUBSYSTEM  III  support  and  UADPS-SP  for  SUBSYSTEM  I  and  II  sup 
port  (whichever  UADPS-SP  hardware  system  is  in  use  at  the 
time)  .  Extensive  secondary  storage  would  be  provided,  so  that 
records  can  be  mass  stored  to  the  capacity  necessary  to  hold 
backup  records  for  three  stock  points.  The  eastern  RASP  site 
would  act  as  the  master  file  maintenance  site  in  the  event 
that  the  NSC  Norf olk-NAVADS  site  goes  down.  All  routine  up¬ 
dates  would  be  distributed  to  the  RASP  sites  as  well  as  to 
all  the  NAVADS  sites  in  order  to  keep  the  PJ\SP  sites  current. 
PJ^SP  sites  would  be  hardened  sites  with  full  AUTODIN  (and 
eventually,  through  the  auspices  of  SPLICE,  full  DDN  capabil¬ 
ity)  in  order  to  receive  the  daily  updates  for  each  of  the 
NSC's  records  under  their  purview  as  kept  in  their  mass  stor¬ 
age  facilities.  The  result  is  that  each  of  the  NAVADS  sites 
would  have  fully  tailored  data  and  file  redundant  back-up, 
not  greater  than  twenty  four  hours  old,  available  at  their 
RASP  site.  If  a  NAVADS  site  goes  down,  the  RASP  site  can  pro 
vide  NAVADS-type  services  by  remote,  through  DDN  terminal 
real  time  access.  RASP  would  download  all  its  held  records 
for  that  NAVADS  site  when  the  stock  point  NAV.ADS  facilities 
are  back  up.  Every  twenty  four  hours  at  staggered  periods, 
each  NAVADS  site  wou±d  transmit  update'.]  CRIP,  NNF ,  NFF ,  NEF, 


\’IF,  and  NXF  files  to  the  RASP  site,  as  well  as  the  latest 


version  of  the  nineteen  SUBSYS'^EM  III  TAPS  (DM)  files.  POS  , 

Historical  Files,  and  all  air  challenge  and  air  clearance 
files  would  also  have  their  updated  versions  transmitted  to 
the  RASP  sites  every  twenty  four  hours.  Eventually,  it  can 
be  envisioned  that,  the  RASP  sites  would  be  updated  on  a 
real-time,  transaction  by  transaction  basis  rather  than  on  a 
twenty  four  hour  batch  update  basis. 

Remote  and  redundant  ADP  operations  and  archival  storage 
are  the  substantive,  current  issues  of  today  as  the  computer 
becomes  the  heart  and  brain  of  complex  organizationa  .  Acci¬ 
dental  or  purposeful  loss  of  processing  capability  without 
back-up  can  result  in  a  long,  virtually  impossible  road  back 
to  a  recovered  state. 

D.  EPILOGUE 

This  thesis  has  given  a  brief  overview  of  the  XAVADS 
system.  It  has  included  an  historical  survev  of  its  origins,  , 

a  brief  walk-through  of  its  three  subsystem.s  ,  and  a  look  at 
current  issues  and  future  implications  facing  the  system  as 
it  now  stands  and  as  it  will  stand  in  its  final  configuration.  , 

Despite  the  restrictions  of  the  Federal  ADP  procurement 
procedures  and  the  overpowering  technological  march  in  ADP 

hardware,  NAVADS  in  the  Navy  Supply  Corps  makes  a  substantive  j 

contribution  towards  bringing  the  naval  service  into  the 
world  of  21st  century  logistics  management.  Real-time,  on¬ 
line  physical  distribution  is  evolving  into  reality,  leaving  I 
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behind  their  analog-batch  progenitors.  The  trinity  of  UADPS-SP 
NAVADS  and  NISTARS,  existing  under  the  SPLICE  comrounications 
umbrella  will  ensure  proper  growth  with  commensurate  technolog¬ 
ical  capabilities  necessary  to  meet  the  relentless  demands 
placed  upon  the  Navy  Supply  System  well  into  the  next  century. 


APPENDIX  A 


SUBSYSTEM  I  AND  II  PROGRAM  SUMMARY 


1.  J-XJlA  -  is  the  NAVADS  Cargo  Routing  Information  File 
Maintenance  File  (CRIF.MF)  program.  This  program  receives 
input,  via  AUTODIN,  from  NAVMTO  to  make  changes,  additions, 
deletions  or  updates  to  records  in  the  CRIF .  The  program 
then  outputs  a  CRIF  Update  and  Error  Report  that  provides 
documentation  of  the  changes. 

2.  J-XJIB  -  The  NAVADS  Real-Time  NFF/NNF  Update  Program, 
which  allows  updates  to  the  file  via  CRT  or  by  auxiliary 
input  via  card  and  tape. 

3.  J-XJIC  -  The  NAVADS  NFF  Update  Program  accepts  NFF  updates 
from  UADPS-SP  for  new  Master  Stock  Item  Record  (MSIR)  additions 
and  from  AUTODIN  to  apply  NSC  Norfolk  Master  NFF  updates  to 
those  NIINs  stocked  by  that  particular  NAVADS  site.  Addition¬ 
ally,  Freight  Classification  updates  from  DLSC  and  Hazardous 
Cargo  Information  from  the  Defense  General  Supply  Center 
(DGSC) ,  Richmond,  VA  are  received  and  inputted  to  NAVADS  via 
this  program. 

4.  J-XJID  -  The  NAVADS  NFF/NNF/HMIS/DLSC  Update  Reformat  Pro¬ 
gram  accepts  three  types  of  inputs  plus  a  program  control 
card.  The  first  are  the  NFF  AUTODIN  Update  Transactions 
(J-XJIDA)  which  are  cumulative  updates  made  by  other  NAVADS 
sites  to  the  master  NFF  at  NSC  Norfolk,  VA.  The  second  is 
the  -Master  NFF  Freight  Classification  Updates  (J-JXIDJ)  used 
only  by  NSC  Norfolk  to  receive  and  input  Freight  Classifica¬ 
tion  updates  received  from  DLSC.  The  third  is  the  Hazardous 
Information  updates  from  DGSC,  used  by  NSC  Norfolk  only,  re¬ 
ceived  via  a  quarterly  tape  transmission.  If  any  of  these 
updates  are  for  NAVADS  interest  or  stocked  items  at  particular 
NAVADS  sites,  the  information  is  written  to  the  J-JXlC  update 
queue  files.  Parameter  control  card  J-XJ2DA  denotes  what 
input  is  in  the  program  for  current  updating. 

5.  J-XjlE  -  The  NAVADS  NFF  Annual  Purge  Programs,  for  other 
than  the  master  site  at  NSC  Norfolk,  screens  the  NIIN  Check 
File  against  the  NFF.  Those  NIINs  found  not  to  be  a  stocked 
item  at  the  NAVADS  site  are  purged  and  sent  to  the  NFF  Purge 
Trigger  File.  This  is  done  to  make  room  in  the  BDP  for  new 
items  by  removing  inactive  records.  This  purge  also  removes 
those  NIIN  records  from  the  NFF  that  are  no  longer  stocked 
at  the  site  due  to  lack  of  demand. 


6..  J-XJlF  -  The  NAVADS  Annual  Purge  Program,  for  the  master 
site  at  Norfolk  only,  uses  the  Purge  Trigger  File  from  the 
individual  NAVADS  sites  to  determine  which  records  should  be 
purged  from  the  master  NFF . 

7.  J-XJIG  -  The  NAVADS  NNF  Update  Program  accepts  updates 
for  addresses  from  a  disk  queue  file.  These  updated  files 
represent  changes  to  the  NNF  via  characteristics  generated 
either  locally  by  the  SPLICE  minicomputer  (presently  the 
Perkin-Elmer  minicomputer),  or  from  updates  received  from 
DAASO.  This  program  produces  file  update  listings,  purge  file 
listings  and  separate  printed  section  listings  for  corrections 
or  updates  forwarded  by  DAASO  or  the  local  NAVADS  minicom.puter 

8.  J-XJ2A  -  NAVADS  NEF  Scan  Program  scans  the  NAVADS  Excep¬ 
tion  File  (NEF)  which,  as  mentioned  before,  is  a  holding  or 
scratch  file  containing  entries  of  an  exceptional  nature 
which  require  further  system  processing  or  attention.  This 
program  produces  five  major  outputs  as  a  result  of  the  system 
scan  of  the  NEF  and  the  user  selected  parameters  as  input  via 
the  Parameter  Control  Cards  (PCC)  and  System  Constant  Area 
(SCA)  parameters.  The  first  of  these  is  the  Air  Challenge 
Listing  which  produces  a  listing  of  shipments  which  do  not 
meet  air  challenge  criteria  and  therefore  should  be  challenged 
as  being  unfit  or  unqualified  for  air  transportation.  "’he 
second  listing  is  the  NAVADS  Exception  Listing,  it  is  used  to 
list  data  base  deficiencies  during  J-XJIB  and  J-XJlC  program 
operations.  Data  elements  in  the  BDP  (the  CRIF,  NNF  and  NFF) 
that  are  missing  or  defective  are  reported  as  well  as  any 
processing  errors  which  may  have  occured  in  the  operation  of 
the  subsystem.  Also  this  listing  identifies  exception  ship¬ 
ments  that  have  been  identified  for  Military  Airlift  Command 
(MAC)  transportation.  The  third  listing,  the  NFF  Updates, 
outputs  only  at  NSC  Norfolk  and  are  used  in  file  maintenance 
site  updates.  The  fourth  function  is  the  production  of  ATCMD 
cards  for  those  transactions  that  have  been  subject  to  a  CRT 
Real-Time  change  to  the  mode  of  shipment  on  the  NAVADS  mini¬ 
computer  and  require  further  or  special  transportation  clear¬ 
ance  via  AUTODIN.  The  last  listing  produced  by  the  NEF  Scan 
Program  is  the  NAVADS  Packing  List.  This  is  a  record  listing 
created  for  each  multi-pack  created  by  the  Shipment  Consoli¬ 
dation  Program  (J-XJ2I)  as  issues  are  released  from  the  NAVADS 
Issue  File  (NIF)  where  IPG  II  and  III  requisitions  are  held 
commensurate  with  workload  demands.  The  listing  is  used  to 
ensure  that  a  shipping  unit  is  packed  and  consolidated  to¬ 
gether  properly  and  to  ensure  that  all  data  elements  are 
correct  and  complete. 

9.  J-XJ2B  -  NAVADS  Real  Time  Issue  Processing  Program  handles 
CRT  inputs  for  issues,  cancellations,  and  modifiers  in  the 
real  time  mode  and  accepts  any  batch  issue  requests  for  high 


priority  and  air  eligible  requisitions.  In  the  BDP  environ¬ 
ment  the  NFF  outpurs  freight  classifications  and  hazardous 
material  information  via  CRT  or  printed  output.  In  the  MCS 
environment,  as  opposed  to  the  BDP  environment,  this  program 
has  seven  major  functions.  The  first,  of  course,  is  to  pro¬ 
cess  requisition  modifiers  and  cancellations  by  searching 
elements  and  files  of  both  Subsystems  II  and  III,  specific¬ 
ally  the  NIF,  the  Shipm.ent  Control  Files  (SCF)  ,  and  the  Requi¬ 
sition  Data  Files  (TAPS/DM  ((2f01)  )  and  performing  the  necessary 
changes  or  cancellations.  The  second  function  is  the  assign¬ 
ment  of  Shipment  Control  Numbers  (SCN)  to  the  requisitions 
received  for  action  by  the  system  except  those  designated  for 
Local  Delivery,  Bearer  Walk-Throughs,  Parcel  Post  or  UPS.  The 
third  function  performs  via  program  J-XJ2B  interaction  with 
the  MCS  in  the  selection  of  shipping  modes.  The  options  for 
shipment  mode  selection  are  shown  in  Table  5  as  extracted  from 
the  NAVADS  Users  .Manual  [Ref.  5:pp.  3-61]  .  The  fourth  function 
is  the  selection  of  the  air  and  surface  routing  channels  to  be 
utilized  for  a  shipment  to  a  particular  UIC.  The  routing 
channel  becomes  an  overriding  informational  component  of  the 
shipping  unit  record.  The  NAVADS  local  site  matches  NNF  UIC 
entities  to  the  CRIF  and  matches  cutoff  dates  to  the  appropri¬ 
ate  routing  channel,  (four  air,  four  surface;  in  fields  41-548 
(.Air)  and  fields  552-1059  (Surface)  )  .  The  fifth  function  is 
air  challenge  processing  allowing  each  NAVADS  site  to  become 
its  own  decentralized  Air  Clearance  Authority  (ACA)  for  Naval 
units.  This  allows  shipments  to  be  directly  cleared  into 
NAV.MTO  for  movement  into  the  military  air  freight  system.  The 
sixth  function  is  the  printing  of  the  DD  1343-1  issue  docu¬ 
ments  at  terminals  in  the  issuing  warehouses.  The  final  func¬ 
tion  of  this  program  within  the  MCS  is  the  writing  of  exception 
data  consisting  of  missing  or  incomplete  file  records  to  the 
NEF  that  are  discrovered  during  Subsystem  II  processing. 

10.  J-XJ2C  -  NAVADS  Batch  Issue  Program  processes  UADPS-SP 
batch  issues  handling  inputs  for  issues,  cancellation,  and 
modifiers  via  card,  magnetic  tape,  or  AUTODIN  batch  media. 

As  in  J-XJ2B  the  batch  issue  program  utilized  BDP  information 
for  creating  shipping  related  listings  and  documents.  In  the 
MCS  environment  the  program  performs  all  those  functions  found 
in  the  real  time  process:  SCN  assignments,  mode  selection, 

NEF  file  writes,  air  challenge  advisories  to  NAVM^O,  and  selec¬ 
tion  of  routing  channels  for  both  air  and  surface  modes .  The 
batch  issue  program,  through  appropriate  parameter  cards,  de¬ 
cides  which  requisitions  go  to  the  NAVADS  Issue  File  (NIF) . 

It  should  be  noted  that  NAVADS  only  permits  IPG  II  and  III 
requisitions  to  go  on  the  NIF  queue  file,  IPG  I  requirements, 
"HI-PRI",  do  not  qualify  for  entry  onto  the  NIF  since  queue 
waiting  time  may  adversely  affect  meeting  UMMIPS  time  frames. 
Air  eligible,  high  priority  documents  are  normally  passed  from 
the  batch  to  the  real  time  processing  program  for  system  entry. 


The  major  NAVADS  output  from  this  program  is  a  magnetic  tape 
of  DD  1348-1  images  for  later  transmission  to  warehouse  loca¬ 
tions  when  the  workload  permits  processing  of  IPG  II  and  III 
requisition  issues.  Three  other  remaining  functions  relate 
to  interface  operations  with  the  TADPS-SP  system  itself. 

Briefly,  the  first  is  the  creation  of  the  NAVADS  Cross-Reference 
File  (NXF)  which  is  a  parallel  record  of  the  MF,  but  only 
utilized  by  the  UADPS-SP  Physical  Inventory  Application.  The 
second  is  the  writing  of  a  DOCID  "ZAU"  record  for  inventory 
issues  t nat  were  processed  directly  without  passing  through 
the  NIF.  Lastly  is  a  write  function  placing  issue  records  on 
a  queue  for  later  processing  by  U.ADPS-SP  to  update  the  Inven¬ 
tory  Suspense  File. 

11.  J-XJ2D  -  NAVADS  DD  1348-1  Print  Program  uses  the  Batch 
Issue  Program  and  the  Shipment  Consolidation  Program  magnetic 
tape  outputs  as  input  to  produce  DD  1348-1  Issue  Documents. 

A  PCC  card  directs  the  sequence  of  DD  1348-1  document  produc¬ 
tion  in  order  to  ensure  shipment  unit  packing  integrity  or  to 
queue  output  in  some  other  specified  or  sequenced  order. 

12.  J-XJ2E  -  NAVADS  NIF/NXF  Reconciliation  Program  ensures 

that  the  NIF  and  NXF  are  in  agreement.  Three  options  are 
available:  NIF/NXF  reconciliation,  NXF/NIF  reconciliation, 

and  mutual  reconsi liation .  The  NIF  is  logically  assumed  to 
be  the  master  file,  additions  and  deletions  are  performed 
only  on  the  NXF.  Option  choices  are  determined  by  PCC  card. 
There  are  two  outputs;  a  NAVADS  Cross  Reference  File  (Updated) 
and  an  NXF  Update  Listing  which  lists  all  changes  made  against 
the  NXF. 

13.  J-XJ2F  -  NAVADS  Process  Change  Location  Program  allows 
the  MCS  to  process  warehouse  location  changes  on  all  those 
records  being  held  in  the  NIF  for  consolidation  or  for  work¬ 
load  considerations.  All  locations,  primary,  secondary  and 
tertiary  are  changed.  This  is  to  ensure  that  all  documenta¬ 
tion  reflects  proper  warehouse  locations  when  the  records 

are  drawn  for  hardcopy  off  the  NIF.  This  producrs  two  outputs, 
the  NAVADS  Issue  File  (Updated)  and  the  NIF  Updates  and  Ex¬ 
ceptions  Listing  which  prints  a  list  of  any  errors  or  excep¬ 
tions  encountered  during  the  update  process  . 

14.  J-XJ2G  -  NAVADS  Produced  Daily  Workload  Planning  File 
Program  uses  the  NIF  to  produce  Workload  Planning  Files  which 
are  used  to  generate  the  Workload  Planning  Reports.  Using  a 
sort  routine,  the  NIF  is  processed  and  a  scratch  file  is  pro¬ 
duced  using  sleected  data  elements  in  the  NIF  records.  'T'his 
sort  file  is  in  Area  of  Country,  UIC  and  Warehouse  Area  format. 
Type  "1"  and  "2"  options  summarize  the  number  of  requisitions, 
weight  and  cube  for  each  warehouse  area  for  individual  UIC's. 

For  the  Type  "2"  option  only,  the  Mandatory  Issue  Date  (MID) 

is  compared  against  the  date  on  the  input  PCC  card,  and  the 


above  summari zations  are  only  given  for  documents  with  julian 
dates  equal  to  or  less  than  the.  date  indicated  on  the  PCC 
card  . 

15.  J-XJ2H  -  NAVADS  Shipment  Workload  Planning  Report  Program 
generates  the  Workload  Planning  Statistic  Report,  the  Workload 
Planning  Report  and  a  special  Commodity  Report.  The  different 
report  formats  are  generated  by  initiating  various  sort  rou¬ 
tines  processed  against  the  records.  This  allows  output  to  be 
sequenced  in  appropriate  order  for  the  reports  themselves. 

16.  J-XJ2I  -  NAVADS  Shipment  Consolidation  Program  uses  the 
NFF,  in  the  BDP  environment,  to  provide  information  to  deter¬ 
mine  consolidation  limits  based  on  the  characteristics  of  the 
material  to  be  shipped.  In  the  MCS  environment  it  is  the 
core  module  central  to  NAVADS*  ability  to  consolidate  ship¬ 
ments  into  properly  combined  shipping  units.  J-XJ2I  consoli¬ 
dates  shipments  and  releases  the  requisitions  from  the  NIF 
for  picking  and  packing  as  a  unitized,  coordinated  block  of 
issues.  Requisitions  on  the  NIF  can  be  supressed  from  release, 
selected  for  release  or  made  ineligible  for  consolidation 
through  the  use  of  either  a  parameter  card  or  a  CR"^  card- 
imaged  screen. 

17.  J-XJ32  -  NATDS  CRIF  Maintenance  Program,  made  available 
to  NAVADS,  is  run  on  a  daily  basis  after  the  J-XJlA  program 
is  run.  This  dual  running  of  both  programs  ensures  that 
shipment  cut  off  dates  present  in  the  CRIF  represent  only 
future  dates.  This  process  of  clearing  expried  cut  off  dates 
for  air  and  surface  shipments  from  both  the  NAVADS  and  NATDS 
systems  is  called  "rolling".  The  CRIF  also  interacts  with 
the  two  issue  input  programs  J-XJ2B  and  J-XJ2C  so  that  proper 
routing  or  forwarding  variables  can  be  incorporated  into  the 
issuing,  packing  and  material  handling  processes. 
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APPENDIX  R 


SUBSYSTEM  III  DOCUMEN'T’ATION  PROGRAM  DESCRIPTIONS 


1.  DD  1387  Military  Shipping  Label  (NON-AIR)  Program 
accesses  the  Shipping  Unit  Data  File  (TAPS/DM (002 ) )  function 
menu.  The  user  reviews  the  UPDSHP  Screen  (002)  to  ensure 
that  all  of  the  required  label  data  have  been  entered  into 
the  Shipment  Unit  record.  The  function  image  SHPLBL  screen  is 
then  used  at  the  CRT  to  input  the  SU.SCN  and  the  number  of 
shipping  labels  required  per  piece  (usually  one) .  Program 
V02040  then  uses  the  contents  of  the  Shipment  Unit  Data  File 
(UPDSHP)  and  the  contents  of  the  Shipment  Label  input  (SHPLBL) 
to  print  the  required  labels  at  the  remote  sites  in  the  ware¬ 
houses.  Screen  (004)  provides  opportunity  for  corrections 

and  Screen  (012)  notifies  the  user  that  the  action  is  completed 
An  example  of  a  DD  1387  is  in  Table  9. 

2.  DD  1387  Military  Shipping  Label  (AIR)  Program  V02210  access 
es  the  Shipment  Unit  Data  File  to  ensure  that  the  shipping  unit 
record  is  complete  and  that  the  mode  of  shipment  is  either  F, 

N,  Q,  R,  T  or  U.  A  CHGMOD  can  be  done  here  in  case  the  mode 
does  not  conform  to  an  air  transport  mode.  ,  The  user  must  then 
access  the  file  to  ensure  that  all  air  challenges  for  the 
shipping  unit  in  question  have  been  cleared  or  resolved.  '^he 
user  selects  the  AIRLBL  function  and  enters  the  SU.SCN  and 

the  number  of  labels  per  piece.  Program  V02210  accepts  all 
UPDSHP,  CHGMOD  and  AIRLBL  function  input  information  and  pro¬ 
duces  a  DD  1387  (AIR)  label  at  the  warehouse  remote  site. 

Screen  format  (021)  is  used  to  notify  the  user  that  the  label 
has  been  transmitted. 

3.  The  Notice  of  Availability  (NOA)  DD1348-5  Program  V01230 
is  the  Access  Data  To  Produce  NOA  routine.  It  utilizes  3 
screen  formats  and  programs  V01240  and  V01250  to  execute  on¬ 
line  NOA  document  production.  This  program  accesses  (TAPS/DM 
(002))  file  information  which  has  the  Shipment  Control  Number 
(SCN) ,  shipping  data  and  the  code  of  the  shipping  office  re¬ 
questing  a  hard  copy  NOA.  The  user  validates  the  shipping 
information  as  correct  and  complete  and  maizes  corrections  as 
necessary  . 

4.  Notice  of  Availability  (NOA)  DD  1348-5  Program  V01240 
Print  Notice  of  Availability,  utilizes  the  data  gathered  by 
program  V01230.  Interaction  now  switches  to  (TAPS/DM (001 )) , 
V01240  cues  the  user  for  the  SU.SCN  of  the  shipment  for  which 
the  NOA  is  required  and  the  code  of  the  shipping  office  which 
requires  the  notification  of  material  availability.  The  DD 
1348-5  NOA  is  printed  at  the  remote  site-office  indicated  by 
the  user. 


5.  Notice  of  Availability  (NOA)  DD  1348-5  Program  V01250 
Update  NOA  File,  is.  the  routine  which  performs  the  on-line 
function  NOAPRD,  which  produces  NOA  card  images  for  AUTODIM 
transmission.  Inputs  to  utility  Screens  025  (corrections)  and 
026  (transaction  completion)  and  information  accumulated  by 
programs  V01230  and  V01240  produce  the  hard  copy  NOA '  s  e.xcept 
in  the  case  of  destination  UIC's  located  in  Germany,  where, 
automatically,  AUTODIN  NOA ' s  are  produced  and  transmitted  in 
place  of  hard  copy  documents. 

6.  GBL  Normal  Front  Sheet  Production  Program  V03170,  (inter¬ 
active  function  GLBNFS)  produces  a  GBL  (SF  1103-A)  front  sheet 
which  requires  a  continuation  sheet.  Screen  017  of  (TAPS/DM 
(003))  is  utilized  to  display  transportation  unit  info-rmation 
so  that  a  user  may  make  corrections  to  the  file,  on-line, 
directly  on  the  CRT.  The  GBL  Number  is  assigned  from  a  block 
of  numbers  assigned  to  a  particular  NAVADS  site.  When  the 
user  transmits,  a  standard  DOD  nine  part  SF-1103-A  is  pro¬ 
duced  with  all  required  block  entries,  accounting  data  and 
endorsements  appropriately  filled  in,  depending  on  the  charac¬ 
teristics  of  the  material  being  shipped.  The  program,  also 
posts  the  Proof  of  Delivery  File  and  History  Data  File,  thus 
closing  out  the  transaction. 

7.  GBL  Front  Only  Edit  Program  V03240  is  only  used  when  a 
single  front  page  is  needed  with  no  continuation  pages  re¬ 
quired.  This  program  displays  GBL  shipment  data  information 
to  the  user  in  GBL  format.  Screen  024  presents  the  GBL  for¬ 
mat  to  the  user  for  corrections  in  case  there  is  an  error, 
Screen  025  displays  the  complete  GBL  for  review  and  any  addi¬ 
tional  corrections.  Screen  026  indicates  a  completed  GBL 
transaction . 

8.  GBL  Front  Only  Print  Program.  V03250  program,  completes  the 
GBLOFS  interactive  function.  An  SF-1103-A,  requiring  no  con¬ 
tinuing  sheets,  is  printed  at  the  remote  site  printer  at  the 
stock  point  shipping  office. 

9.  GBL  ALCO  Front  Page  Print  Program  V03350  is  used  to  pro¬ 
duce  specially  formatted  GBL  documents  for  California  Con¬ 
solidated  (ALCO)  shipments  that  will  use  continuation  sheets. 
The  interactive  function  GBLCFS  is  used  for  this  function. 

ALCO  requires  special  information  on  its  GBL's  for  its  multi¬ 
ple  location  deliveries.  Screen  035  is  used  for  corrections 
to  the  (ALCO)  GBL  record.  Screen  036  is  used  for  notification 
of  a  completed  transaction.  The  har'l  copy  in  printed  to  a 
remote  site  printer  at  the  stock  point  shippin-i  office. 

0.  CBL  Front  Edit  Program  703300  run.i  L  n o  r  .c  t  i '.-e  func¬ 

tion  CBLOFS  with  CRT  Screens  0  30  .in;  0  7.  ‘o  rroh.ic..'  CP'" 
information  concerning  recor  ) 


n  a 


particular  trar.suortat  ion  unit  when  continuation  sheets  are 
not  requir'i’u.  I'he  user  corrects  CBL  document  information  on 
Screen  and  reviews  data  on  Screen  0J1. 

11.  CBL  Front  Only  Print  V03310  takes  the  information  from 
Screen  031  and  produces  a  hard  copy  CBL  that  does  not  require 
a  continuation  sheet.  '^his  program  sends  the  9-part  hard 
copy  to  the  shipping  office,  assigns  a  CBL  number  and  posts 
the  Proof  of  Delivery  File,  History  Data  File  and  any  other 
records  associated  with  the  close  out  of  a  transportation  unit. 

12.  CBL  Normal  Front  Sheet  Production  Program  (V03320)  is 
used  for  the  CBL's  requiring  a  continuation  sheet.  The  program 
utilizes  function  CBLNFS  and  Screen  022  and  023  of  (TAPS/D.M 
(003))  to  produce  a  CBL  for  a  particular  transportation  unit. 
Screen  022  displays  a  CRT  image  of  the  CBL  and  allows  the  user 
to  make  corrections  or  additions  to  information  in  the  CBL's 
record.  Screen  023  advises  the  user  when  the  transaction  is 
complete.  The  system  also  posts  all  POD  and  History  File 
records  and  closes  out  the  transportation  unit.  The  program 
transmits  a  nine  part  CBL  front  sheet  hard  copy,  for  use  by 

the  shippers,  to  a  remote  printer. 

13.  Bill  of  Lading  Continuation  Sheet  Print  Program  V03150 
uses  CRT  Screens  015,  016  and  019  of  (TAPS/D.M  (003).  )  and  func¬ 
tion  BLNCSH  to  produce  the  SF-1109  Continuation  Sheets.  The 
nine-part  DOD  standard  form  is  produced  and  transmitted  to 
the  shipping  office  upon  completion  (Table  13) .  The  (TAPS/DM 
(003))  file  is  flagged  with  a  check  byte  to  show  that  a  con¬ 
tinuation  sheet  has  been  produced  for  a  particular  transporta¬ 
tion  unit.  This  flag  allows  the  GBL  and  CBL  normal  front 
sheets  to  be  produced  when  called  up  out  of  the  003  file.  The 
printing  of  the  continuation  sheets  do  not  cue  the  posting  of 
the  Proof  of  Delivery  and  History  Data  Files,  this  is  done 
only  when  the  front  sheets  are  produced.  Screen  015  is  ued 
when  an  error  returns  the  record  to  the  user  for  correction. 
Screen  016  is  used  to  remove  any  cancelled  requisitions  from 
the  Continuation  Sheet  record  and  to  make  necessary  corrections 
or  deletions.  Screen  019  advises  when  the  transaction  is  com¬ 
plete.  The  Continuation  Sheets,  SF-1109 's,  are  produced 
before  the  SF-1103-A  GBL  front  sheets  and  the  CBL  front  sheets. 

14.  GBL  Continuation  Sheet  for  ALCO  Shipments  Program  V03330, 
GBL  ALCO  Continuation  Print.  Here  the  CRT  interactive  func¬ 
tion  GBLCCS  and  Screen  033  and  034  operate  to  print  the  DOD 
SF-1109-A  ALCO  Continuation  Sheets.  Upon  production  of  the 
SF-1109-A,  a  check  flag  is  sent  to  the  (TAPS/DM003 ) )  file  for 
use  by  Program  V03350  to  allow  printing  of  the  GBL-ALCO  front 
page.  Screen  033  displays  up  to  60  transportation  unit  num¬ 
bers  to  be  shipped  on  one  GBL-ALCO  document.  Screen  034 
advises  that  the  transaction  is  complete  and  that  the  SF-1109-A 


sheets  have  been  transinitted  to  the  stock  point  shipping  area 
remote  terminal. 

15.  DD  1384  Transportation  Control  Movement  Document  (TCMD) 
Access  for  Update-TCMD  Image  Work  File  provides  interactive 
access  to  transportation  unit  records  for  updating  through 
function  UPDTIW. 

16.  DD  1384  TCMD  Update  TCMD  Image  Work  File  Program  726020 
allows  changes  to  records  on  the  file. 

17.  DD  1384  Program  V26040,  Pr int-Transrai t  TCMD  Document 
Program  V26040  allows  printing,  through  interactive  function 
TC.MDPT,  of  hard  copy  TCMD  DD-1384  documents.  The  program 
also  transmits  AUTODIN  card  images  to  a  TCMD  AUTODIN  queue 
file  for  eventual  transmission  to  the  appropriate  ACA  or  WTCA 
The  two  other  programs,  V26060,  Access  for  SCAN-TCMD  Image 
Work  File  and  V26080,  Update-SC.AN  TC.MD  Image  Work  File  are 
used  to  update  record  information  for  Transportation  Unit 
TC.MD '  s  prior  to  their  being  printed  via  the  interactive  func¬ 
tion  TCMDPT. 


TABLE  1 


» 


NAVADS  FREIGHT  CLASSIFICATION/HAZARDOUS  FILE  T-IFF) 
DATA  FORMAT  NAVADS  SUBSYSTEM  I  AMD  II 


Fields 


Description 


1-4 

5-13 

14-19 

20 

21 

22 

23-25 

26 

27 

28-30 

31 

32 
33-34 
35-69 

70 

71-80 

31-84 

85-88 

89-90 

91-93 

94-97 

93-122 

123-147 

148-152 

153-157 

158-207 

208-257 

258-273 

274-296 

297 

298-320 

321-345 

346-350 

351-352 

353-377 

378-384 

335 

386-402 

403-502 

503-576 


Federal  Supplv  Class 
NUN 

Nat  MTR/FRT  Class  (NMFC)  Code 
Less  Than  Truckload  (LTL) 

Air  Dimension  Code 
Data  Last  NFF  Update  -  Year 
Date  Last  NFF  Update  -  Day 
NAVMTO  IND 

NFF  Confirm/Unconfirm  IND 

Water  Commodity  Code 

Type  Cargo  Code 

Special  Handling  Code 

Air  Commodity  Spec  Hndlg  Code 

Freight  Description 

Oversize  Dimension  IND 

NFF  Activity  Stock  Item  IND 

Net  Weight 

Net  Cube 

Hazard-Danger  Cargo  Code 

United  Nations  Class  Code 

United  Nations  Number 

DOT  Label  Primary 

DOT  Label  Secondary 

CFR  Paragraph  Spec  Regs 

CFR  Exceptions 

CFR  Shipping  Name 

CFR  Shipping  Name 

Flashpoint 

Hazard  Class 

CFR  Paragraph  172-100  Symbol 

AFR  71-4  Class 

AFR  71-4  Label 

P\FR  Packing  Paragraph 

Loading  Storage  Group 

IMCO  Label 

Net  Explosive  Weight 
Multiple  ESC/PN  IND 
Filler 

Additional  Hazard  Info 
Filler 


I 


I 


I 


I 


I 


I 


» 


» 


» 
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TABLE  2 


NAVADS  NAiME  AND  ADDRESS  FILE  (NNF) 
DATA  FORMAT  NAVADS  SUBSYSTEM  I  AND  II 


Fields  Description 


1 

2-6 

7-41 

42-76 

77-111 

112-146 

147-181 


Service  Designator  Code 
Unit  Ident  Code  UIC 

In  Clear  Parcel  Post  Address  Line  1 

In  Clear  Parcel  Post  Address  Line  2 

In  Clear  Parcel  Post  Address  Line  3 

In  Clear  Parcel  Post  Address  Line  4 

In  Clear  Parcel  Post  Address  Line  5 

Usual  Air  Mode 

Usual  Surface  Mode 

Aerial  POE 

Aerial  POD 

VJater  POE 

Water  POD 

State  Code 

CONUS  Georgraphic  Area  Code 
CONUS  Geographic  Sub-Area  Code 
Standard  Point  Location  Code 
Government  Bill  of  Lading  Code 
SHIP  TO  UIC 

Break  Bulk  Alt  SHIP  TO  UIC 
Parcel  Post  Zone  Code 
In  the  Clear  Freight  Address 
Local  Delivery  Code 
Mode  Restriction  Code 
Special  Instruction  IND 
UPS  Zone  Code 

Local  Delivery  Instructions 
Date  NNF  Record  Last  Accessed 
In  the  Clear  MARK  FOR  Address 
In  the  Clear  NOA  Address 
Usual  Air  Small  Parcel  Mode 
Usual  Surface  Small  Parcel  Mode 
Filler 


TABLE  3 


CARGO  ROUTING  INFOR-MATION  FILE  (ORIF)_ 
DATA  FORMAT  NAVADS  SUBSYSTEM  I  AND  II 


Fields 


Description 


1-6 

7 

8-32 

33-37 

38-40 


41-43 

44-46 

47-50 

51-65 

66-167 


Unit  Identification  Code 
Type  Activity 
Activity  Name/Hull  Number 
Last  Air  Update  Action 
Air  Operator  (CRT  User) 

Channel  #1  Data  (AIR) 

(41-167) 

Air  Port  of  Embarkation  APOE 
Air  Port  of  Debarkation  APOD 
Cut  Off  Date  for  Shipments 
Information  Source  for  CRIF 
Additional  Routing  Information 


168-294  Channel  #2  Data  (AIR) -same 
295-421  Channel  #3  Data  (.AIR) -same 
422-548  Channel  #4  Data  (AIR) -same 


549-551  Surface  Operator  (CRT  User) 

Channel  #1  Data  (SURFACE) 
552-554  Port  of  Embarkation  POE 

555-557  Port  of  Debarkation  POD 

558-561  Cut  Off  Date  for  Shipments 

562-576  Information  Source  for  CRIF 

577-678  Additional  Routing  Information 


679-805  Channel  #2  Data  (SURFACE ) -same 

806-932  Channel  #3  Data  ( SURFACE) -same 

933-1059  Channel  #4  Data  ( SURFACE) -same 

1060  Air  Update  Indicator 

1061  Surface  Update  Indicator 

1062-1066  Last  Surface  Update  Action 

1067-1083  Home  Port/Shore  Activitv  IND 

1084-1200  Filler 


TABLE  4 


NAVADS  EXCEPTION  FILE  (NEF), 


NEF  List  of  Sub  Files  are  utilized  for  updatina  NAVADS  site 
files  and  communicating  with  the  Master  File  M.aintenance 
Site  at  NSC  Norfold: 

ATCMD  AUTODIN  Record 

NFF  AUTODIN  Record 

Air  Challenge  Message 

ATCMD  AUTODIN  Record  Exception 

CLF  Exception  Record 

NFF  Exception  Record 

Processing  Exception  Record 

NNF  Exception  Record 

Packing  List  Record 

SCN  Assignment  Record 


TABLE  5 


NAVADS  SUBSYSTEM  II  MODE  SELECTION  CRITERIA 
Extract:  UM-XJi?2  p.  3-61 


1.  Local  Delivery  (Mode  9).  is  assigned  when  the  Local  Deliv¬ 
ery  Indicator  in  the  NNF  is  NOT  a  blank. 

2.  A  (Mode  *)  Unable  to  Assign  indicator  is  issued  if  the 
weight  and  cube  data  is  missing  from  the  NNF  or  the  material 
is  hazardous,  oversized  or  security  sensitive. 

3.  (Mode  H)  Air  Parcel  Post  is  assigned  for  IPG  I  and  II 
requisitions  which  do  not  exceed  50  pounds,  4.2  cube  and  for 
which  there  is  no  Air  Parcel  Post  Mode  H  restriction. 

4.  (Mode  G)  Surface  Parcel  Post  is  assigned  to  IPG  III  ship¬ 
ments  where  there  is  no  Mode  G  restriction  or  parcel  post 
restriction . 

5.  (Mode  5)  UPS  is  assigned  to  IPG  I,  II,  III  shipments, 

when  the  restriction  code  are  H  or  G  (parcel  post  restricted) 
and  the  material  is  for  a  CONUS  customer. 

6.  (Mode  F)  MAC  is  selected  to  overseas  IPG  I,  II  shipments 

where  the  UIC  is  not  Mode  F  restricted,  is  not  hazardous, 
oversize  or  security  sensitive.  Shipment  must  exceed  50 
pounds  and  4.2  cube. 

7.  (Mode  Q)  Commercial  Air  is  selected  for  IPG  I,  II  freight 
shipments  when  the  UIC  is  Mode  F  restricted  and  is  hazardous, 
oversize  or  security  sensitive  and  exceeds  50  pounds  and  4.2 
cube . 

8.  CMode  N)  LOGAIR  is  assigned  to  CONUS  IPG  I,  II  shipments 

when  N  is  loaded  in  to  Usual  Air  Mode  for  the  UIC  in  the  NNF 

and  the  weight  is  over  50  pounds  and  4.2  cube. 

9.  (Mode  #)  CONTRUCK  is  assigned  to  IPG  I,  II  shipments 

when  is  loaded  into  the  Usual  Surface  Mode  for  the  UIC 

in  the  NNF.  This  code  is  used  internal  to  stock  points  only 
since  it  is  not  a  valid  MILSTAMP  code. 

10.  (Mode  $)  ALCO  is  assigned  to  CONUS  IPG  I,  II  shipments 
when  "$"  is  loaded  into  the  Usual  Surface  Shipment  Mode  for 
the  UIC  in  the  NNF  and  the  weight  and  cube  exceed  parcel  post 
limits.  ”$"  is  for  internal  use  only. 

11.  (Mode  U)  QUICKTRANS  is  selected  for  CONUS  IPG  I,  II 
freight  shipments  when  the  Usual  Air  Mode  in  the  NNF  is  not 
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Table  5 

MAVADS  SUBSYSTEM  II  MODE  SELECTION  CRITERIA  (cont'd) 


M,  s  or  $  ar  the  weight  and  cube  exceeds  parcel  post 
1 imi t  s  . 

12.  Mole  or'  shipnont  of  IPG  III  freight  requisitions  are 
assi-:ne;  b:i,-.-  .'  on  the  node  loaded  in  to  the  Usual  Surface 
Mode  in  thf_-  M'-T.  ’.rhen  the  Usual  Surface  Mode  byte  is  blank, 
the  node  or  idnipnent  is  assigned  as  follows: 

a)  COd'r'S  Reijuisition  Mode  B  Less  Than  Truck  Load  (LTD 

b)  Overseas  Requisition  Mode  V  SEAVAN 

(If  item,  is  not  oversized,  hazardous  or  security  sensi¬ 
tive)  if  30; 

c)  Mode  Z  Sreakbulk. 


I 

I 


TABLE  6 


NAVADS  SUBSYSTEM  II  LISTINGS  AND  REPORTS 
Extracted:  UM-XJ02  p.  2-26 


Subsystem  II  Management  Control  Subsystem  produces  seven 
different  printed  listings  and  reports  as  a  result  of  requi¬ 
sition  processing  and  interaction  with  Subsystems  I  and  III 
files.  These  reports  are  listed  below: 

1.  Air  Challenge  Listing 

2.  NAVADS  Exception  Listing 

3.  NAVADS  Packing  List 

4.  DD  1348-1  Issue  Documents 

5.  Workload  Planning  Statistics  Listings 

6.  NAVADS  Workload  Planning  Report 

7.  Actual  Planning  Report-Warehouse  Area  Statistics 
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TABLE  7 


NAVADS  SUBSYSTEM  III  INTERACTIVE  FILES  ( TAPS/DM ( XXX H 
Extract:  UM-XJ02  p.  3-80 


1.  The  Requisition  Data  File  (TAPS/DM (001) y  contains  data 
pertinent  to  individual  requisitons.  Inquiries  and  updates 
for  individual  requisitions  are  processed  in  this  with 
thisery  Indicator  in  the  NNF  is  NOT  a  blank, 

2.  The  Shipment  Unit  Data  File  (TAPS/DM (002 ) )  contains  data 
concerning  single  and  multi-requisition  shipment  units. 

DD-1387  labels  are  produced  from  this  file,  it  also  handles 
inquiries  and  updates  concerning  SU ' s  . 

3.  The  Transportation  Unit  Data  File  (TAPS/DM (003 ) )  holds 
data  pertaining  to  shipment  units  grouped  into  Transportation 
Units.  This  file  takes  care  of  transportation  documentation, 
inquiries,  and  updates  concerning  TU ' s  . 

4.  The  Hazardous  Requisiton  Data  File  (TAPS/DM ( 004 ) )  contains 
extra  requisition  data  for  hazardous  material  inquiries  and 
updates  to  hazardous  item  records. 

5.  The  POE/POD  Address  File  (TAPS/DM (005 ) )  contains  in-the- 
clear  addresses  for  Ports  of  Embarkation  and  Debarkation. 

6.  The  Carrier  Name  File  (TAPS/DM (006 ) )  has  in-the-clear 
freight  carrier  names  and  tonnage  statistics. 

7.  The  POS  Shipment  File  (TAPS/DM (007) )  is  an  interactive 
file  queue  that  holds  Proof  of  Shipment  for  Parcel  Post,  UPS, 
Local  Delivery  and  Bearer  Walkthrough  shipments.  Shipments 
are  held  in  this  queue  and  passed  to  UADPS  during  batch  pro¬ 
cessing  to  update  inventory  records. 

8.  The  Mobile  Unit  File  (TAPS/DM (008 ) )  contains  routing 
channels  for  mobile  units. 

9.  The  GBL  History  File  (TAPS/DM (009 ) )  holds  a  record  for 
all  Government  Bills  of  Lading. 

10.  The  Weight  and  Cube  Overflow  File  (TAPS/DM (010) )  contains 
weight  and  cube  for  shipment  units  that  have  more  than  five 
pieces  in  them. 


Table  7 

NAVADS  subsystem  III  INTERACTIVE  FILES  (TAPS/DM  (KXX )  )  (cont'd) 

11.  The  Miscellaneous  File  (TAPS/DM (01 1 ) )  is  used  to  hold 
systems  constants  accessed  at  different  points  of  the  NAVADS 
interactive  process. 

12.  Name  and  Address  File  (NNF)  Updates  (TAPS/DM  (01 3 )  )  inter¬ 
active  method  of  sending  Name  and  Address  file  changes  to  the 
NNF  in  Subsystem  I. 

13.  Freight  Classification  File  (NFF)  Updates  (TAPS/DM (014 ) ) 
interactive  holding  file  used  to  send  Freight  Shipment  changes 
to  the  NFF  in  Subsystem  I. 

14.  The  Freight  History  File  (TAPS/DM (015) )  holds  freight 
history  records  for  shipments  that  have  been  processed  out 
of  the  stock  point. 

15.  The  Parcel  Post/Local  Delivery  Shipment  History  File 
(TAPS/DM (016 ) )  holds  records  for  shipments  that  have  been 
sent  out  to  customers  via  Parcel  Post,  Local  Delivery  or  UPS. 

16.  The  Country  Name  File  (TAPS/DM  (013), )  contains  in  the 
clear  country  names  linked  to  applicable  country  codes. 

17.  The  Appropriations  File  (TAPS/DM (020) )  contains  appro¬ 
priation  line  data  in  order  to  be  accessed  during  the  pre¬ 
paration  of  transportation  documentation. 

18.  The  Transshipment  History  File  (TAPS/DM  ( 02  3 )  ).  contains 
a  record  entry  for  each  transshipment  sent  out  by  the  NAVADS 
activity . 

19.  The  TCMD  Work  Image  File  (TAPS/DM (026 ) )  contains  the  data 
necessary  to  produce  AUTODIN  and  hard  copy  TCMD  documents 
(DD01384)  . 


TABLE  8 


NAVADS  SUBSYSTEM  III  LISTIMGS,  REPORTS,  AND  DOCUMENTS 
Extract:  UM-XJi2f.2  p.  2-26 


Subsystem  III  for  Automated  Documentation  produces  twenty-six 
different  printed  listings,  reports,  and  documents  as  a  result 
of  user  interaction  with  its  file  structure.  These  reports 
are  listed  below: 

1.  Shipments  Scheduled  for  Local  Delivery  (On-line) 

2.  Notice  of  Availability  (NOA)  (DD  1348-5) 

3.  Military  Shipment  Label  (DD  1387) 

4.  Loading  Manifest  (Batch  and  On-line) 

5.  GBL-CBL  Continuation  Sheets 

6 .  GBL  Front  Sheet 

7 .  CBL  Front  Sheet 

8.  Container  Consist  List 

9.  Transportation  Control  and  Movement  Document  (TCMD) 

(DD  1384) 

10.  Local  Delivery/Bearer  Walkthrough  Requisitions  Without 
Proof  of  Shipment  greater  than  2  days  old 

11.  Parcel  Post/UPS  Issues  Without  Proof  of  Shipment  greater 
than  2  days  old 

12.  Transshipment  Report 

13.  Number  of  Requisitions  by  Mode 

14.  PPLDPS  Exception  Listing 

15.  Z98  DOCID  generated  from  Proof  of  Shipment  Error  Report 

16.  Z98  DOCID  Statistical  Report 

17 .  Actual  Date  to  Packing  Update  Report 

18.  Sequential  GBL  Accountability  Listing 

19.  Shipments  Scheduled  for  Local  Delivery  (Batch) 

20.  Requisitions  Late  to  Packing 

21.  Overaged/Delayed  Shipment  Unit  Report 

22.  Requisitions  Shipped  Late 

23.  Transportation  Units  at  Shipping  Report 

24.  Tonnage  Distribution  Report 

25.  Challenged  Status  Report 

26.  TCMD  Image  Work  File  Purge  Report 
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TABLE  16 


AIRBORNE  INTEGRATED  DATA  BASES  DISC  UTILIZATION  IBM  3380 


AIRDILLD  Airbill  Data  1500 

AIRBMSCD  Airbill  Miscellaneous  Data  20.00 

ABCUSTS  Airbill  Customer  Number  Index  250 

ABCUREFS  Airbill  Customer  Ref  Num  Index  50 

ABLANES  Airbill  Lane  Segment  Index  100 

ABABNOS  Airbill  Number  Index  100 

CONSOLE  Consol  Data  75 

CONAIRD  Consol  Airbill  Reference  Data  750 

CONDLTD  Consol  Detail  Data  80 

CNALSTAS  Consol  Airline/Control  Sta  Index  25 

CNORGNS  Consol  Origin  Station  Index  35 

CNDESTS  Consol  Destination  Sta  Index  35 

MANFSTD  Manifest  Data  Base  300 

STROUTD  Station/Route  Primary  Index  5 

ZIPD  Zip  Code  Data  Base  10 

STAZIPS  Station/Zip  Code  Index  8 

TOTAL  Cylinders  5363 

Character  Storage  3,826,000,000 

Rating  DB 

TARIFFD  Tariff  Data  Base  9 

TRFNATS  Tariff  Nat'l  Acc'ts  Secd’ry  Index  1 

TRFLANS  Tariff  Lane  Segment  Secd'ry  Index  1 

TRFXPRS  Tariff  Express  Secd’ry  Index  1 

SCALED  Scale  Data  Base  1 

SCSCTYPS  Scale  Types  Secd'ry  Index  1 

TOTAL  Cylinders  14 

(FOCUS  +  Batch  X  2)  =  28 

Character  Storage  19,900,000 

International  DB 

LOCTNCOD  Location  Code  Data  Base  2 

LOCTNCDI  Location  Code  Primary  Index  1 

FLTSCHED  Flight  Schedule  Data  Base  5 

FLTSCHDI  Flight  Schedule  Primary  Index  1 

FSDESTS  Flight  Sched  Dest  Secd'ry  Index  1 

TOTAL  Cylinders  10 

Character  Storage  7,121,000 


Table  16 

AIRBORNE  INTEGRATED  DATA  BASES  DISC  UTILIZATION  IBM  3  380  (.cont'd) 


Customer-Prospect  DB 

CUSPRSD  Customer/Prospect  Data  Base  250 

CPSHPTD  Customer/Prospect  DB  Summary  1 

CUSPRSI  Customer/Prospect  Primary  Index  10 

CPRNCTLS  Name/Control  Station  Secd'ry  Ind  55 

CPRMGTNS  Merge  to  Number  Secd''ry  Index  1 

CPRSTNMS  Station/Name  Secd'ry  Index  50 

CPCTLKCS  Cont-Sta/Key  Code  Secd'ry  Index  25 

TOTAL  Cylinders  392 

(rOCUS  +  Batch  X  2)  =  784 

Character  Storage  560,000,000 

Accounts  Receivable  DB 

ACTRECD  Accounts  Receivable  Data  Base  640 

ACTRECI  Accounts  Receivable  Pri-Index  100 

ACTRECS  Processing  Date  Secd'ry  Index  80 

TOTAL  Cylinders  820 

Character  Storage  595,000,000 

Data  Dictionary  DB  (EST.) 

DTEDBS  Data  Element  Data  Base  10 

SEGDBS  Segment  Data  Base  10 

DBSDBS  Data  Base  Data  Base  10. 

PCBDBS  Program  Comm  Block  Data  Base  10 

SYSDBS  System  Data  Base  10 

EXTDBS  Extensibility  Data  Base  10 

TOTAL  Cylinders  60 

Character  Storage  42,000,000 

Walker  Interactive  Accounts  Payable 
System  Package 

IMS  Data  Base  (Cylinders)  800 

Character  Storage  570,000,000 


TOTAL  FOCUS  System  Data  Disc  Storage  Utilization 
Cylinders  IBM  3380  7,865 

Total  Character  Storage  5,620,000,000 
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